Subject: [MULTIMOBSEC-API] RE: update of api draft

From: "Shinta Sugimoto \(TO/NRJ\)" <[email-masked]>
Date: Tue, 6 Jun 2006 03:31:13 +0900

Hi Miika,

Thank you for your thorough comments. Please find my comments inline. 

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Monday, June 05, 2006 5:32 PM
> To: Shinta Sugimoto (TO/NRJ)
> Cc: Marcelo Bagnulo Braun; Kristian Slavov (JO/LMF); 
> [email-masked]
> Subject: Re: update of api draft
> 
> On Fri, 2 Jun 2006, Shinta Sugimoto (TO/NRJ) wrote:
> 
> > Hi all,
> >
> > Excuse me for the confusion that I send this email to you (in 
> > unicast), not sending email to the ML <[email-masked]>.
> > Now I have limited connectivity to the public Internet and 
> cannot send 
> > email to the ML (from my personal laptop PC).
> 
> No problem. I attached the original version which I am commenting now.
> 
> > Anyway, I want to make the status update of the draft.  And 
> would like 
> > to you receive your quick feedback if you have any.
> >
> > According to the discussion we had last week, I made some 
> updates to 
> > the API draft.  Attached please find the draft.  In particular, I 
> > would like to hear your comments on some issues that I 
> realized while 
> > I update the document (see paragraphs which begin with 
> "ISSUES:").  A 
> > couple of items were added to the requirements section.  
> Rest of the 
> > changes are after section 6.
> 
> You might e.g. want to request Petri Jokela (nomadiclab) for 
> an issue tracker account in here:
> 
> http://hip4inter.net/cgi-bin/roundup.cgi
> 
> and keep the issues separate from the actual text. But of 
> course, this is a matter of taste.

Ok, thanks. So far, the issues are manageable in my notebook.
When it explodes (maybe soon), I will think more moderate way :)
 
> Here is my feedback for the attached pre-version of the draft:
> 
> > 1. Introduction
> 
> Based on our discussion at HIIT, should we explicitly mention 
> that SHIM6 and HIP probably won't work together? This is 
> related to some other comments below.

Right. I will add some texts in introduction.

> > 5. Requirements
> > ...
> >   o  Notification from application to the shim layer about 
> the status
> >      of the communication.  Note that the notification is made in an
> >      event based manner.  There are mainly two aspects of 
> the feedback
> >      that application or upper layer protocol may provide 
> for the shim
> >      layer, positive and negative feedbacks [NOTE: These 
> feedbacks are
> >      addressed in section 4.3 and section 5.2 of REAP 
> specification]:
> >
> >      *  Positive feedback could be given by the application or upper
> >         layer protocol (e.g.  TCP) to the shim layer 
> informing that its
> >         communication is going well.
> >
> >      *  Negative feedback could be given by the application or upper
> >         layer protocol (e.g.  TCP) to the shim layer 
> informing that its
> >         communication status is not satisfactory.  TCP 
> could detect a
> >         problem when it does not receives expected ACK from 
> the peer.
> >         ICMP error messages delivered to the upper layer 
> protocol could
> >         be a clue for application to detect any kind of 
> problem.  REAP
> >         module may be triggered by these negative feedbacks 
> and invoke
> >         procedure of path exploration.
> >
> >   o  Feedback from application to shim layer.  The 
> application should
> >      be able to inform the shim layer about the timeout values for
> >      detecting failure, for sending keepalives, for starting the
> >      exploration procedure.  In particular, the application 
> should be
> >      able to suppress the keepalives.
> 
> I believe that the last "o" bullet should be a "*" bullet.

This was intentionally separated. The former were dynamic feedback
while the latter is rather static feedback (timeout values).  Yes, both
are common in a sense that they are feedbacks from app to the shim
layer.

> >   o  Turn on/off shim.  The application should be able to request to
> >      turn on/off the multihome support by the shim layer:
> >
> >      *  Apply shim.  The application should be able to explicitly
> >         request the shim layer to apply multihome support.
> >
> >      *  Don't apply shim.  The application should be able to request
> >         the shim layer not to apply the multihome support 
> but to apply
> >         normal IP processing at the IP layer.
> 
> s/multihome support/multihiming support/

Ok.

> The "apply shim" bullet does not really mention whether it is 
> "try" or "must" apply shim. Remember that the peer may or may 
> not be capable of supporting shim. Trying shim means that we 
> can fallback to plain TCP/IP communications. Similarly, must 
> means that we want to use shim or nothing at all. I believe a 
> separate requirement for both would be nice.

Yes, I understand.

> > 6.  Socket Options for Multihomed Shim Layer ..
> >
> > Table 1 provides complete list of the socket options specifically 
> > defined for interface shim layer.  Note that all socket options are 
> > defined at level SOL_SHIM.
> 
> We have two options here (see my comments on intro):
>    a) SOL_SHIM
>    b) SOL_HIP and SOL_SHIM6

Yes. I would say option b) would be "IPPROTO_HIP and IPPROTO_SHIM6"
and I think it makes sense to go with a), IMHO.  See below for the
reasons.

> 
> The first alternative has at least one benefit. If SHIM6 is 
> considered the first step towards full locator/id split (i.e. 
> HIP :), then having this option would guarantee almost 
> transparent migration path from SHIM6 to HIP. The drawbacks 
> are that SHIM6 and HIP cannot be run at the same time for the 
> same socket, and that the socket handler implementation might 
> get quite fat.
> 
> The second alternative reversed benefits and drawbacks when 
> compared to the first alternative.
> 
> Also, one way to think about this are the protocol specific 
> options. How those options should be then defined?

For SHIM6 specific socket options, IPPROTO_IPV6 would be
suitable 'level', I think.  As SHIM6 (in a current form) is designed
in a way that shim deals with identifier and locator both of which
are IPv6 addresses.  So, assumption is that app will natively speak
IPv6 (use IPv6 socket).  In case of HIP, I would assume application
may use either IPv4 socket or IPv6 socket. Or if app opens socket
specifying AF_HIP will result in different case I guess.
Anyway, those options should be specifically treated (defined)
according to the requirements of given protocol of the shim layer.

> 
> I am leaning towards option b) but having the same SO_SHIM 
> socket options for both protocols. However, I am open for ideas.

I think SOL_SHIM would make sense because we are defining
"common" socket API for the generic multihoming shim layer.
The shim layer, by nature, should not be specific to any protocol
family.  And as we say that its "common" for shim approach
which is based on ID/Locator separation (e.g. SHIM6, HIP),
shouldn't we define it in protocol independent way ?

> In addition, should it be IPPROTO_ rather than SOL_? I am 
> little bit unsure on this but I think IPROTO_ is the right 
> one, altough SOL _could be the alias like it is for e.g. 
> IPPROTO_TCP and SOL_TCP.
>
> Opinions, please?

As the generic concept of the "shim layer" should be protocol
independent, it seems reasonable to have prefix "SOL_" rather
than "IPPROTO_."  In my understanding, "IPPROTO_" implies
specific protocol, but "SOL_" could followed by conceptual
layer such as socket or shim layer, IMHO.
Does this make sense ?

> 
> > The first column of the table gives name of the option.  The second 
> > and third columns indicates whether if the option is for retrieving 
> > the date from the kernel or providing data to the kernel (or both).
> > The fifth column indicates if the option deals with binary data or 
> > not.  If the flag is not set, specific data structure (other than
> > int) should be used for data exchange.  The data structure 
> is provided 
> > in the sixth column.
> 
> The first column of the table gives name of the option.  The 
> second and third columns indicates whether the option applies 
> for retrieving the data from the kernel or providing data to 
> the kernel (or both). The fourth column summarizes the 
> purpose of the option. The fifth column indicates if the 
> option deals with integer type of data or not.  If the flag 
> is not set, data structure specific to the socket option 
> (other than int) should be used.  The data structure is 
> provided in the sixth column.
> 
> > Table 1: Socket Options for Multihomed Shim Layer
> 
> * For all option names, please add a SO_ prefix. For example, 
> SHIM_APPLY
>    should be SO_SHIM_APPLY

As far as I understand, prefix of the socket options should
indicate which 'level' the option is for.

> * The flag field is redundant with dtype. Suggest removing 
> flag field and
>    explicitly marking it in dtype field.

Ok.

> * The description field is currently too narrow.

Yes. Will try to expand it.

> * SHIM_STANDBY -> SHIM_HOT_STANDBY

Personally, I'd prefer having less "_", but ... Ok, let's make it HOT :)

> * SHIM_LOCPAIR_PREF and SHIM_LOCPAIR_RECV
>    * I suggest removing this pairing concept and using single locators
>      instead, unles you have a specific need to do otherwise. E.g.
>      have SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF and same for RECV.

I see, maybe we should not introduce new datastructure only for the
reason to pairing the locators.  Noted.

>    * Now, we don't have to introduce another data structure 
> and we can just
>      use regular sockaddr structure for these options.
> 
> > *2: TBD.
> 
> I suggest standard "struct addrinfo" data structure, man 
> getaddrinfo, or:
> 
> ftp://ftp.rfc-editor.org/in-notes/rfc3493.txt

Ok, I think sockaddrs_storage will do the job, as Kristian pointed out.

> After this, I suggest adding a short section on 
> get/setsockopt error values. See man get/setsockopt:
> 
> RETURN VALUES
>       If successful, getsockopt() and setsockopt() return 0;  oth-
>       erwise,  the  functions  return -1 and set errno to indicate
>       the error.

Agree. I will add some texts for treatment of error values.

> 
> We could probably mention explicitly that ENOSYS means that 
> the localhost does not support shim.

Yes. I agree.

> 
> > Figure 2: Socket API system model with shim layer
> 
> How about the following figure instead of the current one:

Hmm, I personally liked the figure that I borrowed from Steven's book
(UNIX Networking Programming, vol. 1) and see how the shim layer
fits into the existing model.  But...

> 
> +------------------------------------------+
> |              Application                 | socket
> +------------------------------------------+
> 
> +------------------------------------------+
> |               SOL_SOCKET                 | generic socket options
> +----------------------------------------- +
> 
> +------------+------------+----------------+
> | IPROTO_TCP | IPROTO_UDP | IPPROTO_ICMPV6 | transport layer sockets
> +------------+------------+----------------+
> 
> +---------------------+--------------------+
> |     IPPROTO_HIP     |   IPPROTO_SHIM6    | shim layer sockets
> +---------------------+--------------------+
> 
> +-------------------+----------------------+
> |    IPROTO_IP      |    IPPROTO_IPV6      | network layer sockets
> +-------------------+----------------------+
> 
> > ISSUE: It may be controversial to introduce a new level 
> SOL_SHIM for 
> > shim specific socket options.  IMHO, we should avoid defining shim 
> > specific socket options for both in level IPPROTO_IP and 
> IPPROTO_IPV6 
> > as it's redundant and seems to be architecturally wrong.
> 
> I think you can just remove this issue.

Given the discussion above, do you think SOL_SHIM is reasonable ?

> 
> > 6.1.  Specifying Shim Specific Ancillary Data ..
> > Table 2: Shim specific ancillary data
> 
> As I noted before we should have separate options for 
> accessing local and peer locators, and the lcinfo should be sockaddr.
> 
> > It should be noted that above cmsg_type are basically for 
> UDP and raw 
> > sockets, not for TCP sockets.
> 
> s/basically/typically/
> 
> It is completely possible to use sendmsg and recvmsg 
> interface for TCP also.

Yes, sendmsg/recvmsg could also be used to TCP socket.
but I wanted to point out that handling of ancillary data per
datagram could also be on UDP/raw sockets.

> > 6.1.1.  SO_LOCPAIR_RECV
> 
> See my previous comments locator pairs and locinfo.
> 
> > 6.1.2.  SO_LOCPAIR_SEND
> 
> See my previous comments locator pairs and locinfo.
> 
> > ISSUE: We should consider error handling in this case, 
> particularly, 
> > in a case where invalid peer locator was specified by the 
> application.  
> > In case of SHIM6, there are two kinds of verifications required in 
> > order to specify send IP packets to the peer's new address; one is 
> > return routability (check if the peer is actually willing 
> to receive 
> > data with the specified locator) and the other is 
> verifications based 
> > on given crypto locator mechanisms[RFC3972], [I-D.ietf-shim6-hba].  
> > What kind of error message should be provided for the caller ?  Is 
> > EINVAL is enough or do we need to introduce new error 
> message (e.g.  
> > EINVALIDLOCATOR) ?
> 
> It is an interesting question... for the time being, I think 
> overloading ENETUNREACH will do just fine.

Ok, noted. I tend to agree with Kristian that EINVALIDLOCATOR
 would be more helpful for app to identify what exactly the error is.
But this should be discussed more, IMHO.

> > 7.  Data Structures
> 
> See my previous comments on these.
> 
> > 8.  Implications for Existing Socket API Extensions ..
> > [RFC3542] defines that IPV6_PKTINFO can be used by application to 
> > influence outgoing datagram (source address, outgoing 
> interface etc.) 
> > and obtain information of incoming datagram (destination address, 
> > receiving interface etc.).  Then a question may rise, what is the 
> > expected consequence of the case where IPV6_PKTINFO and 
> > SHIM_LOCPAIR_SEND is specified at the same time.  Similar 
> question may 
> > rise, what if the IPV6_PKTINFO and SHIM_LOCPAIR_RECV are set at the 
> > same time.
> >
> > ISSUE: We should clarify implications for existing socket API 
> > features, especially IPV6_PKTINFO as it has some implications on 
> > locator selection.  In some case, there might be contradictory case 
> > where IPV6_PKTINFO and SHIM_lOCPAIR_SEND/SHIM_LOCPAIR_RECV are 
> > specified at the same time.
> 
> I suggest changing the question to a solution proposal. 
> Namemely, PKTINFO should specify ULID or transport layer identifier.

Yes, I agree.  The baseline is that shim specific socket API should not
break existing socket API model.  I am still unsure about how we can
resolve preferred outgoing interface, though.

> > 9.  Issues with a Context Shared by Applications
> >
> > When a context is shared by applications, it would be difficult for 
> > the shim layer to handle feedbacks from the applications.  As 
> > mentioned in Section X, an application may provide the shim 
> layer some 
> > feedbacks of timeout values from its own settings.  This 
> implies that 
> > there is potentially a race condition in the shim layer.
> > Further discussions are needed how the shim layer can accommodate 
> > feedbacks from multiple applications within a same context.
> 
> I think the only option how to handle race conditions is to 
> use prioritizing based on process priviledges (super user vs. 
> regular user) and 
> last-process-overwrites-previous-information principle in the 
> case of processes with same access priviledges. Also, I think 
> some of the options should be accessible only with super user 
> priviledges.

Agree that root privilege should override normal user settings.
And partially agree with that some case may be OK to simply updates
the last value.  But there might be other cases too:

request 1: set timeout value T for 2 hours
request 2: set timeout value T for 1.5 hours
request 3: set timeout value T for 3 hours

Suppose if above requests are made sequentially by the entities
who have same privilege level (say all are root), then what should
the shim layer do ?  What Marcelo suggested/mentioned in the
last discussion was to introduce a sort of heuristics to accommodate
these contradictory requests.  One possible option would be to take
demanding request; in above example, timeout value is set to 1.5
hours (request 3 is ignored since it's less demanding).  But I think
appropriate strategy would dependent on socket options or timeout
values.

> > 10.1.  Initial Contact
> 
> In general, I think we should be talking about EIDs, and not 
> addresses, in this section, even though it considers legacy 
> applications. The term "address" is just too vague.

Ok, Noted.

> Also, there is a lot of "loose" text in this section which 
> does not really make any good points. I think the text could 
> be crystallized better, but I don't have any concrete 
> suggestions at this point of time.

I see that Section 10.1 is not clear to the point...
And so far I don't think it's deeply related to the shim specific
socket API.  Anyway, let's put it aside by when the main part
is settled.

> 
> > In connection oriented communication..
> 
> In connection oriented communication, connect() system call 
> is used to make the initial contact to the peer, which 
> *typically* requires IP address and port number to specify 
> the endpoint.
> 
> > It should be noted that the host may also have multiple source 
> > addresses.
> 
> Add: If the application does not specify a source address, 
> the host will assign automatically a local EID.

Yes, in case of HIP, where identifier is more purely treated as
an information to identify endpoint, your statement is valid.

In case of SHIM6, the definition of an identifier is more loose.
That is, an identifier, namely ULID could be any of host's
locators.

> > The different resulting address pair may have different 
> reachability 
> > status so, in order to find a working address pair, it may 
> be required 
> > to explore all the available address pairs (as opposed to 
> explore all 
> > available destination addresses).
> 
> I believe scanning the source addresses is actually not 
> common in shim unaware, legacy applications. Most common 
> scenario 1 x N scanning for reachable destination 
> identifiers. This should be noted in the text.
> 
> > Besides, there is a case where involvement of the shim layer is 
> > expected for handling initial contact.
> 
> Remove the "besides", it is talkative.

Ok.

> > If there exists the context for the EID specified in the connect(), 
> > the initial contact can be made in accordance with the 
> context information.
> 
> This case occurs when there exists the context for the EID 
> specified in the connect(), the initial contact can be made 
> in accordance with the context information.

Ok.

> > 10.2.  Naming at Socket Layer
> > 
> > As IP address is the key information in the two system 
> calls, there is 
> > a question if it should be identifier or locator when shim layer is 
> > present.
> 
> Instead of leaving this open here, let's provoke people to 
> discussion by proposing it to be the identifier.

Ok, let's do that.

> > Appendix B.  Specifying Locator Information ..
> > Note that by using IPv4-mapped address, IPv6 socket may also handle
> > IPv4 packet for exceptional cases.  However, this is not the 
> > recommended due to ambiguity.
> 
> Remove the recommendation. This kind of behaviour has been 
> already deployed, so there is not much we can do.

Ok.

Will update the document and reflecting your comments. Thanks again for
the review!

Regards,
Shinta

_______________________________________________
MULTIMOBSEC-API mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimobsec-api

---

From: Miika Komu <[email-masked]>
Date: Wed, 7 Jun 2006 20:00:14 +0300 (EEST)

> are common in a sense that they are feedbacks from app to the shim

(Maybe you could mention on the dynamic vs. static difference in the text)

> shouldn't we define it in protocol independent way ?

I believe the question boils down to unshared functionality. How to have 
options e.g. for mobility that are not applicable for shim6 but apply for 
HIP. Or public key related things that are shared with btns and hip, but 
do not apply to shim6. On the other hand, if SHIM6 and HIP cannot be used 
simultaneously for a single socket, there should not be a problem?

So, maybe we can use a single shared SHIM contant for the time being and 
split it later if we discover some problems e.g. through implementation 
work.

> independent, it seems reasonable to have prefix "SOL_" rather than 
> "IPPROTO_."  In my understanding, "IPPROTO_" implies specific protocol, 
> but "SOL_" could followed by conceptual layer such as socket or shim 
> layer, IMHO. Does this make sense ?

Regarding to the previous point, maybe IPPROTO_HIP and IPPROTO_SHIM6 could 
be used to separate uncommon features, if necessary. However, seems like 
most of the SOL_XX have a corresponding IPPROTO_XX variable.

So, I am fine with experiment with the SOL_SHIM for the time being.

> Ok, I think sockaddrs_storage will do the job, as Kristian pointed out.

Wasn't this supposed to be a list?

> fits into the existing model.  But...

The SOL_SOCKET was not illustarated correctly in the original figure. 
Also, having the packets flying around when talking about socket layering 
was a little bit misleading.

(SOL_SOCKET bar could also be reversed 90 degrees since it applies to all 
layers, but the current way may be easier to comprehend)

> Given the discussion above, do you think SOL_SHIM is reasonable ?

Sure let's go for that.

> appropriate strategy would dependent on socket options or timeout

As long as the heuristic are simple, that would be fine.

> Will update the document and reflecting your comments. Thanks again for

No problem and apologies for delay in the reply. Remember that Monday is 
cut-off DL, so please remember to submit the draft early :) I hope you or 
Marcelo could present the draft also in the HIP WG in the next IETF.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Kristian Slavov <[email-masked]>
Date: Thu, 08 Jun 2006 11:06:10 +0300

Some comments...

> layer such as socket or shim layer, IMHO.

I agree with both of you. The IPPROTO_HIP/SHIM6 should be used as for 
controlling sockets. I.e. the hip or shim6 daemon would use these socket 
options if it wants to write something to kernel space.
However, the ordinary applications shouldn't be using these, but rather 
SOL_SHIM, as they are not sending HIP or SHIM6 protocol messages, but only 
payload data.

> indicate which 'level' the option is for.

I agree.

> reason to pairing the locators.  Noted.

I think it is good to separate. Allows us using multiple preferred 
addresses (although I'm not sure if that is really useful).

> Ok, I think sockaddrs_storage will do the job, as Kristian pointed out.

Actually, I think Miika has a point here too. The addrinfo structure is 
much more versatile than plain sockaddr_storage. But the penalty is that 
the kernel side (of get/setsockopt) must be careful with all the pointers.
However, I'm not sure if all the information in addrinfo structure is 
actually needed at the shim layer.

-- 
Kristian Slavov, Research Engineer
Ericsson Research, Nomadiclab
Jorvas, Finland

---

From: Miika Komu <[email-masked]>
Date: Thu, 8 Jun 2006 12:03:43 +0300 (EEST)

On Thu, 8 Jun 2006, Kristian Slavov wrote:

>>> I suggest standard "struct addrinfo" data structure, man getaddrinfo, or:
>>> 
> Actually, I think Miika has a point here too. The addrinfo structure is much 
> more versatile than plain sockaddr_storage. But the penalty is that the 
> kernel side (of get/setsockopt) must be careful with all the pointers.

Yes. I checked out the original email, and I meant point 1 (locinfo) and 
not 2:

    *1: pointer to the buffer to which stores array of locator
    information.

    *2: TBD.

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 13 Jun 2006 13:31:25 +0300

Hi Miika,

Sorry for the delay in response. Please find my comments inline.

On Wed, 7 Jun 2006 20:00:14 +0300 (EEST)

> (Maybe you could mention on the dynamic vs. static difference in the text)

Ok, will try to make the difference more visible. This is not reflected
in the latest version of the draft that I just sent to the list but let
me note this.

> do not apply to shim6.

Yes.  I share same view as yours.

> On the other hand, if SHIM6 and HIP cannot be used 

I think so (there should not be a problem) AFAICS.  As far as the shim
protocol (whether if its SHIM6 or HIP else) is exclusively applied for
particular communication, there should not be a critical problem, I think.

Ok.

> So, I am fine with experiment with the SOL_SHIM for the time being.

Ok. And let's solicitate comments from socket API experts during the
next IETF meeting.

> Wasn't this supposed to be a list?

Yes. Sorry for the confusion. Let me clarify.

Regarding the placeholder for the locator information (one or more
locator), we have two options:

sockaddr_storage{} - a protocol independent placeholder for socket
address.  can store IPv4 or IPv6 address. the size is dependent on
implementation (in case of FreeBSD, it's 128 bytes).

addrinfo{} - a protocol independent placeholder for socket address
which is primarily for getaddrinfo.  flexible to use.  can form
an array of locator information.

And we should define how the locator information is handles in
following two cases:

a) argument 'optval' in getsockopt()/setsockopt()
b) ancillary data 'cmsg' to be set for in sendmsg() or
   to be returned by recvmsg().

In a), the buffer pointed by optval may contain one or more
locator.  In b), a single cmsg contains single locator.

Now, let's figure out which data structure is suitable for which
purpose.  First, we may use sockaddr_storage{} for both a) and b).
Especially in case of b), we have less motivation to use addrinfo{}
to store single locator.  I am wondering if use of addrinfo{}
could be expensive for decoding; expensive in a sense that pointers
shoudl be properly managed to maintain an array of locators.
We should note that the data is copied from kernel to userland
and vice versa.

So, I think that choice of sockaddr_storage{} for both a) and b)
would be better.  Opinions ?  Note that the latest draft is written
a) comes with addrinfo{} and b) comes with sockaddr_storage{}.

> The SOL_SOCKET was not illustarated correctly in the original figure. 

You are right. I fixed the figure so that SOL_SOCKET has effect on
whole socket (all the protocol components).

> was a little bit misleading.

I see.  But my intention to put the figure (Figure 2) was to describe
how the shim layer fits in to the system model of the socket API,
rather than the concpetual hierarchy of the protocols.  I've added some
texts in Section 6 and hope they clarify the figure better.

Ok.

Ok.

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Thu, 15 Jun 2006 18:45:43 +0300 (EEST)

> a) comes with addrinfo{} and b) comes with sockaddr_storage{}.

I don't think there is no need to specify multiple addresses in case (b). 
One (ULID) address, either source or destination, can be managed with 
sockaddr_storage should be sufficient.

In case (a), it depends on the specific option. To specify source or 
destination ULID, sockaddr is enough. To specificy locators, we need 
addrinfo.

-- 
Miika Komu                                       http://www.iki.fi/miika/