Subject: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

From: Geoff Huston <[email-masked]>
Date: Tue, 8 Dec 2009 07:14:38 +1100

The WG chairs have received a Working Group Last Call request from the authors of draft-ietf-shim6-multihome-shim-api-11.txt. The intended status of this document is Informational. The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-11

The 2 week WG Last Call will end as of the close of business on Tuesday 22nd December.

As usual, please address all comments to the SHIM6 WG mailing list, and please be clear in your comments to this WG last call if you are supporting the document's submission to the IESG or if you are opposed, or if you are not expressing a view either way. 

Thanks,

 Geoff

WG Co-CHair hat ON

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Dec 2009 17:23:31 +1300

Hi,

First a confession, I have never seriously looked at the earlier
versions, so I apologise if I am covering old ground.

Basically this looks good to me, but I think it isn't quite ready.

I don't really like the first three paragraphs of the Introduction.
The tone is almost apologetic somehow. Could we be more clear,
really just by starting something like

  This document defines socket API extensions by which upper layer
  protocols may be informed about and control the way in which
  multihoming shims in the IP layer manage the dynamic choice of
  locators. Initially it applies to SHIM6 and HIP, but it is defined
  generically.

and then present the main features of the shims and loc-id separation.
(Also see my later comment about the Conclusion section.)

Also in the Introduction

>    This document recommends that the switching of identifier and locator
>    is done only once inside the TCP/IP stack of an endhost.  That is, if
>    multiple shim sub-layers exist at the IP layer, any one of them
>    should be applied exclusively for a given flow.

I agree with this, but does it really belong in the API spec? It seems
more like something for an applicability statement. However, if this
stays, I think it should be very explicit, adding something like:

  Specifically, only one of SHIM6 and HIP should be in use, and neither
  of them are compatible with SCTP or multipath TCP.

(see http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00178.html
for example)

> 2.  Terminology
...
>    o  Endpoint identifier (EID) - The identifier used by the application
>       to specify the endpoint of a given communication.  Applications
>       may handle EIDs in various ways such as long-lived connections,
>       callbacks, and referrals[I-D.ietf-shim6-app-refer].
>       *  In the case of SHIM6, an identifier called a ULID serves as an
>          EID.  A ULID is chosen from locators available on the host.
>       *  In the case of HIP, an identifier called a Host Identifier
>          serves as an EID.  A Host Identifier is derived from the public
>          key of a given host.  For the sake of backward compatibility
>          with the sockets API, the Host Identifier is represented in a
>          form of hash of public key.

We might add a clarification that the EID appears in the standard
socket API as an address, and does not appear in the extensions defined
in this document, which only concern locators.

> 4.  Requirements
...
>    o  Turn on/off shim.  An application should be able to request to
>       turn on or turn off the multihoming support by the shim layer:
>       *  Apply shim.  The application should be able to explicitly
>          request the shim sub-layer to apply multihoming support.
>       *  Don't apply shim.  The application should be able to request
>          the shim sub-layer not to apply the multihoming support but to
>          apply normal IP processing at the IP layer.

We might add a note that this function is also required by any multipath
transport layer such as SCTP or MPTCP, with the details being operating
system dependent.

> 11.  Discussion
> 
>    In this section, open issues are introduced.

This section is non-normative. I think it should be an appendix.

> 12.  Changes

This section seems to be in a strange place, but in any case it should
be marked for deletion by the RFC Editor.

> 14.  Security Considerations

It seems to me that the Unknown Locator mechanism described in
section 11.4 might act as a bypass for the security mechanism
applied by the shim.

> 15.  Conclusion

We don't normally put conclusions in RFCs. Actually, the content
seems to belong in the Introduction.

> Appendix A.  Context Forking
...
>    Another viable approach is to extend SHIM6 protocol by adding
>    capability of exchanging additional information to identify the
>    packet flow from others which needs to be handled by a newly forked
>    context.  The information exchange can be done during the context
>    establishment.  The initiator appends 5 tuple of the packet flow to
>    be handled by the newly forked context.  Note that the additional
>    information provided by the 5 tuple are source and destination port
>    numbers and upper layer protocol.  The information is later used by
>    the shim sub-layer to multiplex the outbound packet flow on the
>    responder side.

Hold on, this is hypothetical protocol design in a non-normative
appendix of an API spec. That seems completely out of place. If
this issue is important, maybe the whole appendix should be a
separate draft?

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Dec 2009 08:42:37 +1300

Hi Miika,

On 2009-12-14 01:41, Miika Komu wrote:
> Brian E Carpenter wrote:
> 
> Hi,
> 
> thanks for your comments! I basically I agree with the rest of your
> comments, but I think the comments on SCTP and multipath TCP needs more
> discussion.
> 
>> ...
>> Also in the Introduction
>>
> this interesting grey area at least for me. Why SHIM6 and HIP are not
> compatible with SCTP and mTCP? Both SHIM6 and HIP are low layer
> mechanisms where as SCTP and mTCP are operating at the transport layer.
> I'm not sure if the SHIM protocols are incompatible with the transport
> layer ones, but they do offer somewhat overlapping functionality.
> 
>> (see
>> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00178.html
>> for example)
> 
> Are you familiar with this work:
> 
> http://tools.ietf.org/html/draft-pierrel-hip-sima-00
> http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf

No, those are new to me. But they do help to show exactly why this
is a grey area. I believe that in shim6 we've always assumed an
incompatibility between shim6 and SCTP (two different algorithms
for changing locators). MPTCP is a bit too new to be sure, but
since it assumes using several locators simultaneously and shim6
assumes using one locator at a time, again it seems incompatible.

But really, that's why I think the whole discussion doesn't
belong in the API spec, except perhaps as an open issue. See
below.

> Just based on your earlier incompatibility statement, I don't really see
> why we should drag SCTP and mTCP all the way here, but I'll wait for
> your comments on the incompatibility first.

Yes, it isn't part of the socket API. I was only suggesting a small note.

There is some discussion of this topic in draft-ietf-shim6-applicability.
My feeling is that probably we should remove it all from the API spec,
and add any missing points to draft-ietf-shim6-applicability, which can
then be an Informative reference.

    Brian

---

From: Miika Komu <[email-masked]>
Date: Sun, 13 Dec 2009 14:41:01 +0200

Brian E Carpenter wrote:

Hi,

---

From: Miika Komu <[email-masked]>
Date: Sun, 13 Dec 2009 23:26:49 +0100

Brian E Carpenter wrote:

Hi,

I think adding a reference to the SHIM6 applicability document is a good 
idea.

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 14 Dec 2009 12:23:35 +0800

Hi Brian,

Thank you very much for your comments. Please find my comments inline.

Let me address my opinion on compatibility issue of SHIM/HIP and SCTP/multi-path TCP in another threads. 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Sunday, December 13, 2009 5:24 AM
> To: [email-masked]
> Cc: Kristian Slavov; [email-masked]; Shinta Sugimoto
> Subject: Re: [shim6] WG Last Call for 
> draft-ietf-shim6-multihome-shim-api
> 
> Hi,
> 
> First a confession, I have never seriously looked at the 
> earlier versions, so I apologise if I am covering old ground.
> 
> The tone is almost apologetic somehow. Could we be more 
> clear, really just by starting something like
> 

Ok, let us revise the text as you suggeted.  BTW, the intention of the three paragraphs in the
currerent text is to provide explanation to people who ask "HIP/SHIM6 aims at
hiding locators from applications, doesn't it? Then why you specify something
which requires applications to deal with locators?"  But I guess texts were not so clear.

> I agree with this, but does it really belong in the API spec? 
> It seems more like something for an applicability statement. 
> However, if this stays, I think it should be very explicit, 
> adding something like:

I agree that this is a generic issue in SHIM6/HIP and it is more like applicability statement.
Let us revise the text.

> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg0

Let me comment in different thread about compatibility issue.

> We might add a clarification that the EID appears in the 
> standard socket API as an address, and does not appear in the 
> extensions defined in this document, which only concern locators.

I agree. Let us add this note in the explanation about EID.

> We might add a note that this function is also required by 
> any multipath transport layer such as SCTP or MPTCP, with the 
> details being operating system dependent.

I think this relates to the compabilitiy issue, so let me state my view in differnet thread.

> This section is non-normative. I think it should be an appendix.

Ok.

> > 12.  Changes
> 
> This section seems to be in a strange place, but in any case 
> it should be marked for deletion by the RFC Editor.

Ok.

> It seems to me that the Unknown Locator mechanism described 
> in section 11.4 might act as a bypass for the security 
> mechanism applied by the shim.

Let me clarify if I undertand your comment.
Yes, application may provide locator(s) which the multihome shim sub-layer
may not be aware of.  In principle, the reaction of the multihome shim sub-layer
must be aligned with what is stated in Section 7.2 (Locator Verification) of
RFC 5533.  Besides, I think an error message must be returned to the application
when it tries to use unknown locator as the source address for outbound user traffic.
Does this cover your concern?

> > 15.  Conclusion
> 
> We don't normally put conclusions in RFCs. Actually, the 
> content seems to belong in the Introduction.

Ok.

> Hold on, this is hypothetical protocol design in a 
> non-normative appendix of an API spec. That seems completely 
> out of place. If this issue is important, maybe the whole 
> appendix should be a separate draft?

I see.  I agree that it should be outside the API spec.
The importance of the issue depends on frequency of the scenario
(i.e., multiple applications share the same SHIM6 context), I think.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 14 Dec 2009 12:41:16 +0800

Hi again,

With regard to the compability issue with SHIM6 and SCTP (and potentially multi-path TCP), I agree that we may need to put small note in the API spec.  I checked the applicability document (draft-ietf-shim6-applicability) and I think what is stated in Section 7.3 (Shim6 and SCTP) is reasonable.

So, I think we should notes in the document stating that:

- it is not recommended to apply SHIM6 (or HIP) and any other multihoming mechanism to the IP flow by referring to draft-ietf-shim6-applicability
- we recommend SCTP and multipath TCP to have API to turn on/off the multihoming feature (so that the TCP/IP stack can avoid conflicting use of multihoming mechanisms)

Regards,
Shinta

> Sent: Sunday, December 13, 2009 8:43 PM
> To: [email-masked]
> Cc: [email-masked]; Kristian Slavov; [email-masked]; Shinta Sugimoto
> > comments, but I think the comments on SCTP and multipath TCP needs 
> > more discussion.
> > 
> >> ...
> >> Also in the Introduction
> >>
> >> I agree with this, but does it really belong in the API spec? It 
> >> seems more like something for an applicability statement. 
> However, if 
> >> this stays, I think it should be very explicit, adding 
> something like:
> >>
> No, those are new to me. But they do help to show exactly why 
> this is a grey area. I believe that in shim6 we've always 
> assumed an incompatibility between shim6 and SCTP (two 
> different algorithms for changing locators). MPTCP is a bit 
> too new to be sure, but since it assumes using several 
> locators simultaneously and shim6 assumes using one locator 
> at a time, again it seems incompatible.
> 
> belong in the API spec, except perhaps as an open issue. See below.
> 
> > 
> >>> 4.  Requirements
> >> ...
> >> We might add a note that this function is also required by any 
> >> multipath transport layer such as SCTP or MPTCP, with the details 
> >> being operating system dependent.
> > 
> > Just based on your earlier incompatibility statement, I 
> don't really 
> > see why we should drag SCTP and mTCP all the way here, but 
> I'll wait 
> > for your comments on the incompatibility first.
> 
> My feeling is that probably we should remove it all from the 
> API spec, and add any missing points to 
> draft-ietf-shim6-applicability, which can then be an 
> Informative reference.
> 
>     Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2009 08:45:43 +1300

Agreed.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2009 08:51:44 +1300

On 2009-12-14 17:23, Shinta Sugimoto wrote:
...
> Does this cover your concern?

Well, I don't quite understand how an extra locator provided by the
upper layer can ever pass the CGA/HBA test. So I don't really understand
the unknown locator mechanism, I guess. Maybe it can never work in the
case of SHIM6 or HIP but might work with some other kind of shim?

    Brian

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 18 Dec 2009 13:56:49 +0800

Hi,

I am sorry for the delay in resonse. Let me address my view on the unknown locator issue.

> Sent: Monday, December 14, 2009 8:52 PM
> To: Shinta Sugimoto
> Cc: [email-masked]; Kristian Slavov; [email-masked]
> Subject: Unknown locator [WG Last Call for 
> draft-ietf-shim6-multihome-shim-api]
> 
> >> section 11.4 might act as a bypass for the security 
> mechanism applied 
> >> by the shim.
> > 
> > Yes, application may provide locator(s) which the multihome shim 
> > sub-layer may not be aware of.  In principle, the reaction of the 
> > multihome shim sub-layer must be aligned with what is stated in 
> > Section 7.2 (Locator Verification) of RFC 5533.  Besides, I 
> think an 
> > error message must be returned to the application when it 
> tries to use unknown locator as the source address for 
> outbound user traffic.
> Well, I don't quite understand how an extra locator provided 
> by the upper layer can ever pass the CGA/HBA test. So I don't 
> really understand the unknown locator mechanism, I guess. 
> Maybe it can never work in the case of SHIM6 or HIP but might 
> work with some other kind of shim?

After re-thinking, I think we need to handle two cases: 1) application sending data with unknown source/destination locator, 2) application requesting for using unknown source/destination locator.

As to the former case, the multihoming shim sub-layer must reject the request and send an error message to the application.  The reason is simply because the packet with unknown source locator will be dropped by the peer and sending packet to unknown destination locator should be prohibited for security reasons.

As to the latter case, the multihoming shim sub-layer should do the following:

In response to the request for using unknown source locator:

- check if the requested source locator is available on any of the local interface
- if the source locator is available, then the multihoming shim sub-layer MAY initiate procedure to update its own locator list with the peer

In response to the request for using unknown destination locator, the situation is a bit tricky because it means that the application somehow knows another locator (IP address) to reach the peer while the multihoming shim sub-layer does not.  I am not sure if we have such a case in reality, but in theory, I think the multihoming shim sub-layer must reject the request at least in the case of SHIM6.  In the case of HIP, I am clarifying this with HIP experts what to do.

Any comments?

p.s., Please note that I will be off-line for 1.5 days from now due to business travel.  Will be able to response on 19 December.

Regards,
Shinta

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Dec 2009 09:48:56 +1300

Shinta,

I think that is all correct, and it will be interesting to hear
the response from the HIP experts.

Thanks
   Brian Carpenter

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 19 Dec 2009 08:33:42 -0800

> > work with some other kind of shim?

I think it will work with HIP, perhaps not with shim6.  My original read of the draft was that this case of the shim rejecting a locator provided by the application was covered by returning an error EINVALIDLOCATOR (see the very end of Section 5 of the draft).

It seemed to me that the open issue in practice is to be able to pass the knowledge of a new possible locator that was provided by the application to the shim layer, and might then need to be communicated via some kind of upcall to a user-space daemon doing reachability tests, etc.  However, such an upcall is outside the scope of this draft.

>
> After re-thinking, I think we need to handle two cases: 1)
> application sending data with unknown source/destination
> locator, 2) application requesting for using unknown
> source/destination locator.
>
> As to the former case, the multihoming shim sub-layer must
> reject the request and send an error message to the
> application.  The reason is simply because the packet with
> unknown source locator will be dropped by the peer and
> sending packet to unknown destination locator should be
> prohibited for security reasons.

Can you clarify what you mean by 1)?  I thought that applications sent data to identifiers in this framework.

> - check if the requested source locator is available on any

(I would add that "available" means that it is configured on some interface and it satisfies whatever requirements are placed on its usage by the shim, such as hba).

> - if the source locator is available, then the multihoming
> shim sub-layer MAY initiate procedure to update its own
> locator list with the peer

By specifying as a MAY, applications will have a hard time relying on it being available.  Applications may know best about what locators they want to use with the shim.  I'd rather see API that supported two cases:  1) locators provided as hints to the shim (where the MAY would apply), and 2) locators provided as application policy that should not be ignored; i.e. the connection should perhaps fail if the locators provided cannot be used

>
> In response to the request for using unknown destination
> locator, the situation is a bit tricky because it means that
> the application somehow knows another locator (IP address) to
> reach the peer while the multihoming shim sub-layer does not.
>  I am not sure if we have such a case in reality, but in

this seems to me to be potentially a very common case for locator- and shim-aware applications

> theory, I think the multihoming shim sub-layer must reject
> the request at least in the case of SHIM6.  In the case of
> HIP, I am clarifying this with HIP experts what to do.

For HIP, I would suggest to accept it.  I think it will probably be a common case because it allows the application to provide locators to HIP so that HIP doesn't have to do an address lookup based on the HIT.

I suggest to clarify what is meant by "unknown locator" perhaps in the terminology section.  I think that what is meant by the text is that there is an existing context and a locator is provided that was not announced in the context handshake or subsequent signaling.  However, what about providing a locator before any context is set up?  In this case, all locators are potentially "unknown" at this stage.  I think it is a very important piece of the API for HIP to be able to have an application associate a destination locator with a destination HIT (and also source locator for policy or reachability purposes) before the HIP handshake starts.  For shim6, before context is set up, it seems that identifiers are initial contact locators too. In this case, it should be defined what should be the behavior if bind(address) conflicts with SHIM_LOC_LOCAL_SEND or if connect(address) conflicts with SHIM_LOC_PEER_SEND.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 19 Dec 2009 19:20:55 +0100

Henderson, Thomas R wrote:

Hi,

> Can you clarify what you mean by 1)?  I thought that applications sent data to identifiers in this framework.

I think this means that e.g. application has cached a ULID (HIT, etc) 
and starts just sending data to it.

> (I would add that "available" means that it is configured on some interface and it satisfies whatever requirements are placed on its usage by the shim, such as hba).

Right.

> By specifying as a MAY, applications will have a hard time relying on it being available.  Applications may know best about what locators they want to use with the shim.  I'd rather see API that su…

This could be returned in the return value of setsockopt().

At least in HIP, an unkown source locator could trigger an UPDATE with 
LOCATOR parameter being sent. An unknown peer locator, could trigger an 
ECHO_REQUEST being sent. Thomas, is the latter part going to be included 
in the new revision of RFC5206 (this was also mentioned in different 
context in the cross-family handover paper)?

(Shinta: I don't think we need to go this detailed with the API draft)

> this seems to me to be potentially a very common case for locator- and shim-aware applications

HIP needs this. I would assume that the application is giving hints 
because the system is unable to find a locator matching to the ULID. So, 
just saying "no" does not work for HIP even though it may work for 
routable ULIDs in SHIM6.

To be more specific, the native API for HIP assumes that the SHIM layer 
can cache locators in the following sections:

http://tools.ietf.org/html/draft-ietf-hip-native-api-09
4.1.1. HIP Wildcard Addresses
4.2.1. Resolver Usage
4.6. Explicit Handling of Locators

The native API for HIP is in IESG evaluation, so I think it would be 
nice to resolve this issue quickly.

> For HIP, I would suggest to accept it.  I think it will probably be a common case because it allows the application to provide locators to HIP so that HIP doesn't have to do an address lookup based…

+1. I think it should be technically feasible check in the SHIM socket 
handler if the socket is bound to a AF_INET6 or or AF_HIP socket.

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 21 Dec 2009 19:38:03 +0800

Hi Thomas,

Thanks for your comments and please find my responses inline. 

> From: Henderson, Thomas R [mailto:[email-masked]] 
> Sent: Sunday, December 20, 2009 1:34 AM
> To: Shinta Sugimoto; Brian E Carpenter
> Subject: RE: Unknown locator [WG Last Call 
> fordraft-ietf-shim6-multihome-shim-api]
> 
> 
> 
> > >
> > > upper layer can ever pass the CGA/HBA test. So I don't really 
> > > understand the unknown locator mechanism, I guess.
> > > Maybe it can never work in the case of SHIM6 or HIP but 
> might work 
> > > with some other kind of shim?
> 
> I think it will work with HIP, perhaps not with shim6.  My 
> original read of the draft was that this case of the shim 
> rejecting a locator provided by the application was covered 
> by returning an error EINVALIDLOCATOR (see the very end of 
> Section 5 of the draft).
> 
> It seemed to me that the open issue in practice is to be able 
> to pass the knowledge of a new possible locator that was 
> provided by the application to the shim layer, and might then 
> need to be communicated via some kind of upcall to a 
> user-space daemon doing reachability tests, etc.  However, 
> such an upcall is outside the scope of this draft.
> 
> >
> application 
> > sending data with unknown source/destination locator, 2) 
> application 
> > requesting for using unknown source/destination locator.
> >
> reject the 
> > request and send an error message to the application.  The 
> reason is 
> > simply because the packet with unknown source locator will 
> be dropped 
> > by the peer and sending packet to unknown destination 
> locator should 
> > be prohibited for security reasons.
> 
> Can you clarify what you mean by 1)?  I thought that 
> applications sent data to identifiers in this framework.

1) means that application sends data by specifying source (or destination) locator, e.g., by using SHIM_LOC_*_SEND socket options.  Of course, the socket is bound to identifiers.  But the app can optionally specify source and/or desination locator(s).  This is what we call "locator management" and we define socket API extensions for enabling this function.

> (I would add that "available" means that it is configured on 
> some interface and it satisfies whatever requirements are 
> placed on its usage by the shim, such as hba).
> 
> > - if the source locator is available, then the multihoming shim 
> > sub-layer MAY initiate procedure to update its own locator 
> list with 
> > the peer
> 
> By specifying as a MAY, applications will have a hard time 
> relying on it being available.  Applications may know best 
> about what locators they want to use with the shim.  I'd 
> rather see API that supported two cases:  1) locators 
> provided as hints to the shim (where the MAY would apply), 
> and 2) locators provided as application policy that should 
> not be ignored; i.e. the connection should perhaps fail if 
> the locators provided cannot be used

I understand.  I am not quite sure if we should say MAY or SHOULD here, but I think application should be fine as far as it knows if the requested locator was accepted or not (by the multihoming shim sub-layer).  The acceptance means the result of the first check, i.e., availability of the source locator.  Reachability from the source locator in question to the peer's locator, is another issue, IMO.  So, what about this:

- the multihoming shim sub-layer MUST return the result to the application (whether the request for updating the source locator was accepted or not. When it is accepted, it means that the locator list is updated accordingly. When it's rejected, no changes to the locator list).
- when the request for updating the source locator was accepted, the multihoming shim sub-layer SHOULD initiate the procedure to update the locator list accordingly.

> locator, the 
> > situation is a bit tricky because it means that the application 
> > somehow knows another locator (IP address) to reach the 
> peer while the 
> > multihoming shim sub-layer does not.
> the request 
> > at least in the case of SHIM6.  In the case of HIP, I am clarifying 
> > this with HIP experts what to do.
> 
> For HIP, I would suggest to accept it.  I think it will 
> probably be a common case because it allows the application 
> to provide locators to HIP so that HIP doesn't have to do an 
> address lookup based on the HIT.

Ok, I think this point is where we have significant difference with HIP and SHIM6.  Identifiers are non-routable in case of HIP.

> I suggest to clarify what is meant by "unknown locator" 
> perhaps in the terminology section.  I think that what is 
> meant by the text is that there is an existing context and a 
> locator is provided that was not announced in the context 
> handshake or subsequent signaling.  However, what about 
> providing a locator before any context is set up?  In this 
> case, all locators are potentially "unknown" at this stage.

Ok, I understand.

Then we should probably prepare an exceptional case for HIP when the app requests to use specific destination locator(s) for a given application session even when there is no context associated with the socket.  Such a case should be the initial case where the app starts communication with the peer using HIP.
 
> I think it is a very important piece of the API for HIP to be 
> able to have an application associate a destination locator 
> with a destination HIT (and also source locator for policy or 
> reachability purposes) before the HIP handshake starts.

Ok.  Let me come back with a proposal soon (tomorrow at the latest).  I guess we should have separate email thread for this topic.

>For 
> shim6, before context is set up, it seems that identifiers 
> are initial contact locators too. In this case, it should be 
> defined what should be the behavior if bind(address) 
> conflicts with SHIM_LOC_LOCAL_SEND or if connect(address) 
> conflicts with SHIM_LOC_PEER_SEND.

Well, the conflict actually does not matter.  The IP address used for bind() is the source identifier, and the IP address used for connect() is the destination identifier.  As you mentioned, identifier and locator could be identical, or could be different.  SHIM_LOC_LOCAL_SEND will give the source locator and SHIM_LOC_PEER_SEND will give the destination locator.

Regards,
Shinta

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 21 Dec 2009 10:12:25 -0800

Shinta, some more responses inline below

> From: Shinta Sugimoto [mailto:[email-masked]]
> Sent: Monday, December 21, 2009 3:38 AM
> To: Henderson, Thomas R; Brian E Carpenter
> 1) means that application sends data by specifying source (or
> destination) locator, e.g., by using SHIM_LOC_*_SEND socket
> options.  Of course, the socket is bound to identifiers.  But
> the app can optionally specify source and/or desination
> locator(s).  This is what we call "locator management" and we
> define socket API extensions for enabling this function.

Yes, but I meant that applications send data by send, sendto, or sendmsg, and SHIM_LOC_*_SEND are set as socket options, not as ancillary data to sendmsg().  So it seemed to me that case 1) becomes case 2).

>
> > >
> > > As to the latter case, the multihoming shim sub-layer
> should do the
> > > following:
> > >
> > > - check if the requested source locator is available on
> any of the
> > > local interface
> >
> I understand.  I am not quite sure if we should say MAY or
> SHOULD here, but I think application should be fine as far as
> it knows if the requested locator was accepted or not (by the
> multihoming shim sub-layer).

Can you explain the difference between SHIM_LOC_LOCAL_PREF and SHIM_LOC_LOCAL_SEND?  To me, it is the difference between SHOULD and MUST.  It seems to me that if you make SHIM_LOC_LOCAL_SEND either a MAY or a SHOULD, it becomes basically the same as SHIM_LOC_LOCAL_PREF, and applications can't tell the shim that they insist on specific locators being used (regardless of what REAP, ICE, etc. may learn).

> The acceptance means the result
> of the first check, i.e., availability of the source locator.
>  Reachability from the source locator in question to the
> peer's locator, is another issue, IMO.  So, what about this:
>
> - the multihoming shim sub-layer MUST return the result to
> the application (whether the request for updating the source
> locator was accepted or not. When it is accepted, it means
> that the locator list is updated accordingly. When it's
> rejected, no changes to the locator list).
> - when the request for updating the source locator was
> accepted, the multihoming shim sub-layer SHOULD initiate the
> procedure to update the locator list accordingly.
>
> > >
> Ok, I think this point is where we have significant
> difference with HIP and SHIM6.  Identifiers are non-routable
> in case of HIP.
>
> Then we should probably prepare an exceptional case for HIP
> when the app requests to use specific destination locator(s)
> for a given application session even when there is no context
> associated with the socket.  Such a case should be the
> initial case where the app starts communication with the peer
> using HIP.
>
> Ok.  Let me come back with a proposal soon (tomorrow at the
> latest).  I guess we should have separate email thread for this topic.
>
> >For
> Well, the conflict actually does not matter.  The IP address
> used for bind() is the source identifier, and the IP address
> used for connect() is the destination identifier.  As you
> mentioned, identifier and locator could be identical, or
> could be different.  SHIM_LOC_LOCAL_SEND will give the source
> locator and SHIM_LOC_PEER_SEND will give the destination locator.
>

If SHIM_LOC_*_SEND are not possible to be set before a shim6 context is set up, then I agree that it seems to not make a difference.

- Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 23 Dec 2009 01:04:33 +0800

Hi Thomas,

Please find my responses inline. Please note that my proposal for handling unknown destination locator in case of HIP will follow in separate email.

> Sent: Tuesday, December 22, 2009 3:12 AM
> > > I think it will work with HIP, perhaps not with shim6.  
> My original 
> > > read of the draft was that this case of the shim 
> rejecting a locator 
> > > provided by the application was covered by returning an error 
> > > EINVALIDLOCATOR (see the very end of Section 5 of the draft).
> > >
> > > It seemed to me that the open issue in practice is to be able to 
> > > pass the knowledge of a new possible locator that was provided by 
> > > the application to the shim layer, and might then need to be 
> > > communicated via some kind of upcall to a user-space daemon doing 
> > > reachability tests, etc.  However, such an upcall is outside the 
> > > scope of this draft.
> > >
> > > >
> > > Can you clarify what you mean by 1)?  I thought that applications 
> > > sent data to identifiers in this framework.
> >
> options.  
> > Of course, the socket is bound to identifiers.  But the app can 
> > optionally specify source and/or desination locator(s).  
> This is what 
> > we call "locator management" and we define socket API 
> extensions for 
> > enabling this function.
> 
> Yes, but I meant that applications send data by send, sendto, 
> or sendmsg, and SHIM_LOC_*_SEND are set as socket options, 
> not as ancillary data to sendmsg().  So it seemed to me that 
> case 1) becomes case 2).

Sorry, I should have said "1) means that application sends data by specifying source (or destination) locator, e.g., by using SHIM_LOC_*_SEND ancillary data."  Please note that application can sendmsg() with ancillary data by using SHIM_LOC_*_SEND.  See 6.2 () and Table 2 in page 27.  It's a bit tricky, but SHIM_LOC_*_SEND is also a socket option.

But, I think I understand your point.  Regardless of how the source (or destination) locator is set, we need to specify how the multihoming shim sub-layer would react in response to the request made by the application.  The important differences that we need to distinguish would be the degree of demand from application.  So, I 

> > > (I would add that "available" means that it is configured on some 
> > > interface and it satisfies whatever requirements are 
> placed on its 
> > > By specifying as a MAY, applications will have a hard 
> time relying 
> > > on it being available.  Applications may know best about what 
> > > locators they want to use with the shim.  I'd rather see API that 
> > > supported two cases:  1) locators provided as hints to the shim 
> > > (where the MAY would apply), and 2) locators provided as 
> application 
> > > policy that should not be ignored; i.e. the connection should 
> > > perhaps fail if the locators provided cannot be used
> >
> > I understand.  I am not quite sure if we should say MAY or SHOULD 
> > here, but I think application should be fine as far as it 
> knows if the 
> > requested locator was accepted or not (by the multihoming shim 
> > sub-layer).
> 
> Can you explain the difference between SHIM_LOC_LOCAL_PREF 
> and SHIM_LOC_LOCAL_SEND?  To me, it is the difference between 
> SHOULD and MUST.  It seems to me that if you make 
> SHIM_LOC_LOCAL_SEND either a MAY or a SHOULD, it becomes 
> basically the same as SHIM_LOC_LOCAL_PREF, and applications 
> can't tell the shim that they insist on specific locators 
> being used (regardless of what REAP, ICE, etc. may learn).

SHIM_LOC_LOCAL_PREF allows application to set the "preference" of a given locator.  Preference is indicated by the integer value (0 to 255).  SHIM_LOC_LOCAL_SEND allows application to set the local locator for the IP packets to be sent from the socket.  SHIM_LOC_LOCAL_PREF is thus useful for the application to prioritize local locator to be used for sending IP packets when there are candidate locators.  I agree with your view on the difference between the two.  I.e., the difference could be translated into different degrees of demand to be fulfilled by the shim; SHIM_LOC_LOCAL_PREF indicates rather weak demand (MAY or SHOULD), and SHIM_LOC_LOCAL_SEND indicates rather strong (MUST) demand.

Now, let's get back to the original discussion.  I agree with your view that we should distinguish two cases: 1) source and/or destination locator is set by the application with rather weak demand (MAY or SHOULD), and 2) source and/or destination locator is set by application with strong demand (MUST).  However, I don't think the connection must fail (even when the specified source and/or destination locator with strong demand was not available).  I think the application is fine as far as it knows if the request was accepted or not.  Does this make sense to you?

> >  Reachability from the source locator in question to the peer's 
> > locator, is another issue, IMO.  So, what about this:
> >
> > - the multihoming shim sub-layer MUST return the result to the 
> > application (whether the request for updating the source 
> locator was 
> > accepted or not. When it is accepted, it means that the 
> locator list 
> > is updated accordingly. When it's rejected, no changes to 
> the locator 
> > list).
> accepted, the 
> > multihoming shim sub-layer SHOULD initiate the procedure to 
> update the 
> > locator list accordingly.
> >
> > > >
> probably be 
> > > a common case because it allows the application to 
> provide locators 
> > > to HIP so that HIP doesn't have to do an address lookup 
> based on the 
> > > HIT.
> >
> > Ok, I think this point is where we have significant difference with 
> > HIP and SHIM6.  Identifiers are non-routable in case of HIP.
> >
> meant by 
> > > the text is that there is an existing context and a locator is 
> > > provided that was not announced in the context handshake or 
> > > subsequent signaling.  However, what about providing a locator 
> > > before any context is set up?  In this case, all locators are 
> > > potentially "unknown" at this stage.
> >
> > Ok, I understand.
> >
> when the 
> > app requests to use specific destination locator(s) for a given 
> > application session even when there is no context 
> associated with the 
> > socket.  Such a case should be the initial case where the 
> app starts 
> > communication with the peer using HIP.
> >
> > > I think it is a very important piece of the API for HIP 
> to be able 
> > > to have an application associate a destination locator with a 
> > > destination HIT (and also source locator for policy or 
> reachability 
> > > purposes) before the HIP handshake starts.
> >
> latest).  
> > I guess we should have separate email thread for this topic.
> >
> > >For
> > > shim6, before context is set up, it seems that identifiers  are 
> > >initial contact locators too. In this case, it should be  defined 
> > >what should be the behavior if bind(address)  conflicts with 
> > >SHIM_LOC_LOCAL_SEND or if connect(address)  conflicts with 
> > >SHIM_LOC_PEER_SEND.
> >
> > Well, the conflict actually does not matter.  The IP 
> address used for 
> > bind() is the source identifier, and the IP address used 
> for connect() 
> > is the destination identifier.  As you mentioned, identifier and 
> > locator could be identical, or could be different.  
> > SHIM_LOC_LOCAL_SEND will give the source locator and 
> > SHIM_LOC_PEER_SEND will give the destination locator.
> >
> 
> If SHIM_LOC_*_SEND are not possible to be set before a shim6 
> context is set up, then I agree that it seems to not make a 
> difference.

I agree.  SHIM_LOC_*_SEND has no effect when there is no multihome shim context associated with the socket (and thus the behavior of bind() would not conflict with SHIM_LOC_LOCAL_SEND).

Regards,
Shinta

---

From: Geoff Huston <[email-masked]>
Date: Wed, 23 Dec 2009 06:46:34 +1100

> As usual, please address all comments to the SHIM6 WG mailing list, and please be clear in your comments to this WG last call if you are supporting the document's submission to the IESG or if you a…

Thanks to all for your reviews and subsequent discussion.

Its evident to me that there is still further work to be done on this document, and I do not feel that I saw a general consensus form the WG activity that the document is ready to be sent ot the IESG.

Could I ask the authors to submit another rev of the document that includes the outcomes of the issues discussed in the last couple of weeks, and we'll then try to see if these changes are able to address the outstanding concerns in a further round of a WG Last Call.

many thanks,

    Geoff

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 24 Dec 2009 02:20:37 +0800

Hi Geoff and all,

Thanks for your support and suggestion.  Yes, I agree.  Let us revise the document taking all the comments/suggestions that we received into account, and go for another round of WGLC.

Let me clarify the list of substantial comments that we received besides quite a few editorial comments.  The following three are the ones that we received so far, I think.  We (authors, I mean) will make sure that we have enough discussion on the ML and outcomes are addressed in the next revision of the draft.

1. Compatibility issue with other mutlihoming mechanism (SCTP, multi-path TCP)

	Reached to an agreement to state recommendation.

2. Treatment of unknown locator

	Seems that the treatment for unknown source locator is agreed.  With regard to the treatment for unknown destination locator, an exceptional handling for HIP (when the application provides destination locator to the HIP in the initial stage of communication) has been proposed and clarification/confirmation by HIP experts is needed.

3. Need for including ULID pair in the shim locator data structure (struct shim_locator{})

	Discussion has not been started yet on the ML.

Regards,
Shinta

> From: Geoff Huston [mailto:[email-masked]] 
> Sent: Wednesday, December 23, 2009 4:47 AM
> To: [email-masked]
> Cc: Kristian Slavov; [email-masked]; Shinta Sugimoto; Jari Arkko
> > The WG chairs have received a Working Group Last Call 
> request from the 
> > authors of draft-ietf-shim6-multihome-shim-api-11.txt. The intended 
> > status of this document is Informational. The document (and 
> the draft 
> > history) is at 
> > http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-11
> > 
> > As usual, please address all comments to the SHIM6 WG 
> mailing list, and please be clear in your comments to this WG 
> last call if you are supporting the document's submission to 
> the IESG or if you are opposed, or if you are not expressing 
> a view either way. 
> > 
> 
> Its evident to me that there is still further work to be done 
> on this document, and I do not feel that I saw a general 
> consensus form the WG activity that the document is ready to 
> be sent ot the IESG.
> 
> Could I ask the authors to submit another rev of the document 
> that includes the outcomes of the issues discussed in the 
> last couple of weeks, and we'll then try to see if these 
> changes are able to address the outstanding concerns in a 
> further round of a WG Last Call.
> 
> many thanks,
> 
>     Geoff
> 
> 
> 
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 23 Dec 2009 14:31:06 -0800

Shinta, a few more replies inline on this thread:
>
> Sorry, I should have said "1) means that application sends
> data by specifying source (or destination) locator, e.g., by
> using SHIM_LOC_*_SEND ancillary data."  Please note that
> application can sendmsg() with ancillary data by using
> SHIM_LOC_*_SEND.  See 6.2 () and Table 2 in page 27.  It's a
> bit tricky, but SHIM_LOC_*_SEND is also a socket option.
>
> But, I think I understand your point.  Regardless of how the
> source (or destination) locator is set, we need to specify
> how the multihoming shim sub-layer would react in response to
> the request made by the application.  The important
> differences that we need to distinguish would be the degree
> of demand from application.  So, I

Your above sentence trailed off but I think you were basically agreeing to clarify this point.

>
> SHIM_LOC_LOCAL_PREF allows application to set the
> "preference" of a given locator.  Preference is indicated by
> the integer value (0 to 255).  SHIM_LOC_LOCAL_SEND allows
> application to set the local locator for the IP packets to be
> sent from the socket.  SHIM_LOC_LOCAL_PREF is thus useful for
> the application to prioritize local locator to be used for
> sending IP packets when there are candidate locators.  I
> agree with your view on the difference between the two.
> I.e., the difference could be translated into different
> degrees of demand to be fulfilled by the shim;
> SHIM_LOC_LOCAL_PREF indicates rather weak demand (MAY or
> SHOULD), and SHIM_LOC_LOCAL_SEND indicates rather strong
> (MUST) demand.
>
> Now, let's get back to the original discussion.  I agree with
> your view that we should distinguish two cases: 1) source
> and/or destination locator is set by the application with
> rather weak demand (MAY or SHOULD), and 2) source and/or
> destination locator is set by application with strong demand
> (MUST).  However, I don't think the connection must fail
> (even when the specified source and/or destination locator
> with strong demand was not available).  I think the
> application is fine as far as it knows if the request was
> accepted or not.  Does this make sense to you?

I agree that the policy to fail or not should be with the application and not with the shim, so long as the shim accurately notifies the application.

Regards,
Tom