Subject: Re: comments on draft-ietf-shim6-proto-05.txt
From: marcelo bagnulo braun <[email-masked]>
To: David Meyer <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Mon, 23 Oct 2006 19:43:15 +0200

El 23/10/2006, a las 19:33, David Meyer escribió:

>

>>>
>>>   Context forking     A mechanism which allows ULPs that are aware of
>>>                       multiple locators to use separate contexts for
>>>
>>> dmm> a bit confusing, since ULPs shouldn't be aware of locators
>>> dmm> in any event? what is an example of a ULP that would be
>>> dmm> "locator-aware"?
>>>
>>
>>
>> this seems a fundamental issue with the concept of forking...
>>
>> The idea of forking is to allow applications that "know better" to
>> actually manage the locators used for the communication through an
>> extended API. of course the basic idea is that apps are not aware of
>> locators, but in case of special apps that want to be able to do this,
>> this is how they do it. Several folks have brougth that this was
>> needed... maybe them can provide exmaples of such apps...
>
> dmm> such examples would be very helpful. I'm still a little
> dmm> leary of the lack of "information hiding", although that has
> dmm> its ups and downs too...

will try to find some.

i think i have some in some old emails, will try to dig them out...

>>>
>>> 7.6.  Context confusion
>>>
>>>   Since each end might garbage collect the context state we can have
>>>   the case when one end has retained the context state and tries to
>>> use
>>>   it, while the other end has lost the state.  We discussed this in
>>> the
>>>   previous section on recovery.  But for the same reasons, when one
>>>   host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
>>>   other end might end up allocating that context tag as CT(local) for
>>>   another ULID pair, e.g., <A3, B1> between the same hosts.  In this
>>>   case we can not use the recovery mechanisms since there needs to be
>>>   separate context tags for the two ULID pairs.
>>>
>>>   This type of "confusion" can be observed in two cases (assuming it
>>> is
>>>   A that has retained the state and B has dropped it):
>>>
>>>   o  B decides to create a context for ULID pair <A3, B1>, and
>>>      allocates X as its context tag for this, and sends an I1 to A.
>>>
>>>
>>>
>>>
>>>
>>> Nordmark & Bagnulo      Expires November 16, 2006              [Page
>>> 58]
>>>
>>> Internet-Draft               Shim6 Protocol                     May
>>> 2006
>>>
>>>
>>>   o  A decides to create a context for ULID pair <A3, B1>, and starts
>>>      the exchange by sending I1 to B. When B receives the I2 message,
>>>      it allocates X as the context tag for this context.
>>>
>>>   In both cases, A can detect that B has allocated X for ULID pair
>>> <A3,
>>>   B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
>>>   Thus A can detect that B must have lost the context for <A1, B1>.
>>>
>>>   The confusion can be detected when I2/I2bis/R2 is received since we
>>>   require that those messages MUST include a sufficiently large set 
>>> of
>>>   locators in a Locator List option that the peer can determine
>>> whether
>>>   or not two contexts have the same host as the peer by comparing if
>>>   there is any common locators in Ls(peer).
>>>
>>> dmm> not really sure how this works. Is it not possible to have
>>> dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty
>>> dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing
>>> dmm> locator sets for peer)? Or is the "sufficiently slowly
>>> dmm> changing locator sets" assumption operative here?
>>>
>>
>> the assumption here is that there is no situation of merging hosts,
>> meaning that if two contexts are initiated with a disjoint set of
>> locators, they will remain disjoint during the lifetiem of the 
>> context,
>> and the situation where two contexts have disjoint sets and then later
>> on one of them adds new locators that interject with another 
>> previously
>> disjoint context is not supported. This is what the above assumption 
>> is
>> expressing... makes sense?
>
> dmm> yes. Maybe exactly that text, or something like it, would clarify?
>

ok, i will add a similar text in this section

Regards, marcelo

Delivery-date: Mon, 23 Oct 2006 17:34:40 +0000
Date: Mon, 23 Oct 2006 10:33:37 -0700
From: David Meyer <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: shim6-wg <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 23, 2006 at 05:57:53PM +0200, marcelo bagnulo braun wrote:
> Hi Dave,
> 
> thank you very much for your detailed review, i think it has greatly 
> helped to improve the readability of the draft.

	My pleasure. Glad I could help.

> I have included most of your suggestions in the next version 06 of the 
> draft.
> 
> Remaining issues that i have not included in the draft and required 
> additional discussion imho are commented below...

	Comments in line (search for dmm>).

	thnx,

	--dmm

> 
> 
> 
> El 20/07/2006, a las 17:00, David Meyer escribió:
> >
> >	Folks,
> >
> >	In Montreal Kurtis asked me if I'd read through the base
> >	documents for readability (so this is a bit gen-art-ish)
> >	and content. Here's my first such reveiew.
> >
> >	My comments are in-line (search for dmm>).
> >
> >	Thnx,
> >
> >	--dmm
> >
> ...
> >1.  Introduction
> >
> 
> ...
> >
> 
> >1.5.  Renumbering Implications
> >
> >
> ....
> >
> >   But IP addresses are also used as ULID, and making the communication
> >   survive locators becoming invalid can potentially cause some
> >   confusion at the upper layers.  The fact that a ULID might be used
> >   with a different locator over time open up the possibility that
> >   communication between two ULIDs might continue to work after one or
> >   both of those ULIDs are no longer reachable as locators, for example
> >   due to a renumbering event.  This opens up the possibility that the
> >   ULID (or at least the prefix on which it is based) is reassigned to
> >   another site while it is still being used (with another locator) for
> >   existing communication.
> >
> >dmm> what are there security implications of this, if any?
> >
> 
> Jim Bound have raised similar concerns in his review, so i have deleted 
> the last two paragraphs of this section included below, eliminating the 
> possibility of keeping the ULID after a renumbering event.
> would that be enough?

dmm> sure

> 
> >   In the worst case we could end up with two separate hosts using the
> >   same ULID while both of them are communicating with the same host.
> >
> >   This potential source for confusion can be avoided if we require 
> >that
> >   any communication using a ULID must be terminated when the ULID
> >   becomes invalid (due to the underlying prefix becoming invalid).  If
> >   that behavior is desired, it can be accomplished by explicitly
> >   discarding the shim state when the ULID becomes invalid.  The 
> >context
> >   recovery mechanism will then make the peer aware that the context is
> >   gone, and that the ULID is no longer present at the same locator(s).
> >
> >   However, terminating the communication might be overkill.  Even when
> >   an IPv6 prefix is retired and reassigned to some other site, there 
> >is
> >   a very small probability that another host in that site picks the
> >   same 128 bit address (whether using DHCPv6, stateless address
> >   autoconfiguration, or picking a random interface ID [11]).  Should
> >   the identical address be used by another host, then there still
> >   wouldn't be a problem until that host attempts to communicate with
> >   the same peer host with which the initial user of the IPv6 address
> >   was communicating.
> >
> >   The protocol as specified in this document does not perform any
> >action when an address becomes invalid.  As we gain further
> >   understanding of the practical impact of renumbering this might
> >   change in a future version of the protocol.
> >
> >
> >
> ...
> >
> >2.  Terminology
> >
> >
> 
> >
> >   Context forking     A mechanism which allows ULPs that are aware of
> >                       multiple locators to use separate contexts for
> >
> >dmm> a bit confusing, since ULPs shouldn't be aware of locators
> >dmm> in any event? what is an example of a ULP that would be
> >dmm> "locator-aware"?
> >
> 
> 
> this seems a fundamental issue with the concept of forking...
> 
> The idea of forking is to allow applications that "know better" to 
> actually manage the locators used for the communication through an 
> extended API. of course the basic idea is that apps are not aware of 
> locators, but in case of special apps that want to be able to do this, 
> this is how they do it. Several folks have brougth that this was 
> needed... maybe them can provide exmaples of such apps...

dmm> such examples would be very helpful. I'm still a little
dmm> leary of the lack of "information hiding", although that has
dmm> its ups and downs too...
> 
> this is the same issue that you brought up in...
> 
> 
> >4.2.  Context Forking
> >
> >   It has been asserted that it will be important for future ULPs, in
> >   particular, future transport protocols, to be able to control which
> >   locator pairs are used for different communication.  For instance,
> >dmm> sort of violates the property that ULIDs appear to be
> >dmm> locators to the ULPs. What are the implications of
> >dmm> exposing the ULID/Locator mapping to the ULPs or other
> >dmm> applications that use the shim6 service?
> 
> ...
> 
> >
> >4.  Protocol Overview
> >
> ...
> >   The shim6 protocol operates in several phases over time.  The
> >   following sequence illustrates the concepts:
> >
> >
> >   o  An application on host A decides to contact B using some upper-
> >      layer protocol.  This results in the ULP on A sending packets to
> >      B. We call this the initial contact.  Assuming the IP addresses
> >      selected by Default Address Selection [12] and its extensions 
> >[13]
> >      work, then there is no action by the shim at this point in time.
> >      Any shim context establishment can be deferred until later.
> >
> >dmm> inconsistent use of Host X and X to refer to the same
> >dmm> thing. scan the entire doc for this.
> >
> 
> i am not sure about this....
> 
> we use Host A and host B and then we simply use A and B in order to 
> make the reading less loaded...

> 
> do you think it is unclear or a matter of style?

dmm> understand. it wasn't a huge issue, just style, I suppse

> ...
> >7.  Establishing ULID-Pair Contexts
> >
> 
> >
> >   In all the cases the result is that the peer without state receives 
> >a
> >   shim message for which it has to context for the context tag.
> >
> >dmm> BTW, inconsistent use of shim v. shim6
> >
> 
> shim is used as the generic concept of a middle layer and shim6 is used 
> as the specific implementation of a shim described in this document. 
> These two terms should be used like this consistently in the whole 
> docuemnt, makes sense?

dmm> I was just taking a look at that, and I guess its fine.

> >
> ...
> >
> >7.6.  Context confusion
> >
> >   Since each end might garbage collect the context state we can have
> >   the case when one end has retained the context state and tries to 
> >use
> >   it, while the other end has lost the state.  We discussed this in 
> >the
> >   previous section on recovery.  But for the same reasons, when one
> >   host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
> >   other end might end up allocating that context tag as CT(local) for
> >   another ULID pair, e.g., <A3, B1> between the same hosts.  In this
> >   case we can not use the recovery mechanisms since there needs to be
> >   separate context tags for the two ULID pairs.
> >
> >   This type of "confusion" can be observed in two cases (assuming it 
> >is
> >   A that has retained the state and B has dropped it):
> >
> >   o  B decides to create a context for ULID pair <A3, B1>, and
> >      allocates X as its context tag for this, and sends an I1 to A.
> >
> >
> >
> >
> >
> >Nordmark & Bagnulo      Expires November 16, 2006              [Page 
> >58]
> >
> >Internet-Draft               Shim6 Protocol                     May 
> >2006
> >
> >
> >   o  A decides to create a context for ULID pair <A3, B1>, and starts
> >      the exchange by sending I1 to B. When B receives the I2 message,
> >      it allocates X as the context tag for this context.
> >
> >   In both cases, A can detect that B has allocated X for ULID pair 
> ><A3,
> >   B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
> >   Thus A can detect that B must have lost the context for <A1, B1>.
> >
> >   The confusion can be detected when I2/I2bis/R2 is received since we
> >   require that those messages MUST include a sufficiently large set of
> >   locators in a Locator List option that the peer can determine 
> >whether
> >   or not two contexts have the same host as the peer by comparing if
> >   there is any common locators in Ls(peer).
> >
> >dmm> not really sure how this works. Is it not possible to have
> >dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty
> >dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing
> >dmm> locator sets for peer)? Or is the "sufficiently slowly
> >dmm> changing locator sets" assumption operative here?
> >
> 
> the assumption here is that there is no situation of merging hosts, 
> meaning that if two contexts are initiated with a disjoint set of 
> locators, they will remain disjoint during the lifetiem of the context, 
> and the situation where two contexts have disjoint sets and then later 
> on one of them adds new locators that interject with another previously 
> disjoint context is not supported. This is what the above assumption is 
> expressing... makes sense?

dmm> yes. Maybe exactly that text, or something like it, would clarify?

> 
> >   The requirement is that the old context which used the context tag
> >   MUST be removed; it can no longer be used to send packets.  Thus A
> >   would forcibly remove the context state for <A1, B1, X>, so that it
> >   can accept the new context for <A3, B1, X>.  An implementation MAY
> >   re-create a context to replace the one that was removed; in this 
> >case
> >   for <A1, B1>.  The normal I1, R1, I2, R2 establishment exchange 
> >would
> >   then pick unique context tags for that replacement context.  This 
> >re-
> >   creation is OPTIONAL, but might be useful when there is ULP
> >   communication which is using the ULID pair whose context was 
> >removed.
> >
> >dmm> what happens if an "old" I1 was floating around and gets
> >dmm> there before the "new" I1 and still within I1_TIMEOUT?
> >
> 
> I1 new and I1 old are supposed to be equal, right? so if the first one 
> arrives first than the second it shouldn't matter i guess...
> ...
> >
> >
> >7.20.  Receiving I2bis messages and sending R2 messages
> >
> >   A host MUST silently discard any received I2bis messages that do not
> >   satisfy all of the following validity checks in addition to those
> >   specified in Section 12.2:
> >
> >   o  The Hdr Ext Len field is at least 3, i.e., the length is at least
> >      32 octets.
> >
> >   Upon the reception of an I2bis message, the host extracts the ULID
> >   pair and the Forked Instance identifier from the message.  If there
> >   is no ULID-pair option, then the ULID pair is taken from the source
> >   and destination fields in the IPv6 header.  If there is no FII 
> >option
> >   in the message, then the FII value is taken to be zero.
> >
> >dmm> is there a way to get a I2bis with no ULID-pair option but
> >dmm> with a (non-zero) FII option? If so, which case is that? If not,
> >dmm> what does the host do if it receives that?
> 
> both scenarios are supported
> the packet can have a ULID option or not and may have a FII option or 
> not. all 4 combination are possible...

dmm> ok, that wasn't clear to me when I first read the doc
> 
> ...
> 16.  Security Considerations
> 
> >
> >   o  Every control message of the shim6 protocol, past the context
> >      establishment, carry the context tag assigned to the particular
> >      context.  This implies that an attacker needs to discover that
> >      context tag before being able to spoof any shim6 control message.
> >      Such discovery probably requires to be along the path in order to
> >      be sniff the context tag value.  The result is that through this
> >      technique, the shim6 protocol is protected against off-path
> >      attackers.
> >
> >dmm> why can't I just search the 2^47 space? I suppose an
> >dmm> implementation will detect this.
> >
> 
> we haven't considered the possibility of this attack
> the attack that the protocol is protected (sort of) is a memory 
> consuption doS attack, in which the attacker generates many shim6 
> context in order to exaust the memory of the victim. the protection 
> against this attack is that a 4 way handshake is required to establish 
> the shim6 context. This implies that the attacker needs to spend 
> additional resources in order to launch the attack, these resourses 
> would also be needed to launch the CT exahustion attack that you 
> describe, do you think this would be enough protection for this case?

dmm> I'm not a secuity expert (duh :-)), but yes, it would seem so.

> thanks again for your careful review...

	Any time. Its my pleasure.

	--dmm

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature
Content-Disposition: inline

--ZPt4rx8FFjLCG7dd--

Delivery-date: Mon, 23 Oct 2006 15:59:17 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt
Date: Mon, 23 Oct 2006 17:57:53 +0200
To: David Meyer <[email-masked]>

Hi Dave,

thank you very much for your detailed review, i think it has greatly 
helped to improve the readability of the draft.

I have included most of your suggestions in the next version 06 of the 
draft.

Remaining issues that i have not included in the draft and required 
additional discussion imho are commented below...

El 20/07/2006, a las 17:00, David Meyer escribió:
>
> 	Folks,
>
> 	In Montreal Kurtis asked me if I'd read through the base
> 	documents for readability (so this is a bit gen-art-ish)
> 	and content. Here's my first such reveiew.
>
> 	My comments are in-line (search for dmm>).
>
> 	Thnx,
>
> 	--dmm
>
...
> 1.  Introduction
>

...
>

> 1.5.  Renumbering Implications
>
>
....
>
>    But IP addresses are also used as ULID, and making the communication
>    survive locators becoming invalid can potentially cause some
>    confusion at the upper layers.  The fact that a ULID might be used
>    with a different locator over time open up the possibility that
>    communication between two ULIDs might continue to work after one or
>    both of those ULIDs are no longer reachable as locators, for example
>    due to a renumbering event.  This opens up the possibility that the
>    ULID (or at least the prefix on which it is based) is reassigned to
>    another site while it is still being used (with another locator) for
>    existing communication.
>
> dmm> what are there security implications of this, if any?
>

Jim Bound have raised similar concerns in his review, so i have deleted 
the last two paragraphs of this section included below, eliminating the 
possibility of keeping the ULID after a renumbering event.
would that be enough?

>    In the worst case we could end up with two separate hosts using the
>    same ULID while both of them are communicating with the same host.
>
>    This potential source for confusion can be avoided if we require 
> that
>    any communication using a ULID must be terminated when the ULID
>    becomes invalid (due to the underlying prefix becoming invalid).  If
>    that behavior is desired, it can be accomplished by explicitly
>    discarding the shim state when the ULID becomes invalid.  The 
> context
>    recovery mechanism will then make the peer aware that the context is
>    gone, and that the ULID is no longer present at the same locator(s).
>
>    However, terminating the communication might be overkill.  Even when
>    an IPv6 prefix is retired and reassigned to some other site, there 
> is
>    a very small probability that another host in that site picks the
>    same 128 bit address (whether using DHCPv6, stateless address
>    autoconfiguration, or picking a random interface ID [11]).  Should
>    the identical address be used by another host, then there still
>    wouldn't be a problem until that host attempts to communicate with
>    the same peer host with which the initial user of the IPv6 address
>    was communicating.
>
>    The protocol as specified in this document does not perform any
> action when an address becomes invalid.  As we gain further
>    understanding of the practical impact of renumbering this might
>    change in a future version of the protocol.
>
>
>
...
>
> 2.  Terminology
>
>

>
>    Context forking     A mechanism which allows ULPs that are aware of
>                        multiple locators to use separate contexts for
>
> dmm> a bit confusing, since ULPs shouldn't be aware of locators
> dmm> in any event? what is an example of a ULP that would be
> dmm> "locator-aware"?
>

this seems a fundamental issue with the concept of forking...

The idea of forking is to allow applications that "know better" to 
actually manage the locators used for the communication through an 
extended API. of course the basic idea is that apps are not aware of 
locators, but in case of special apps that want to be able to do this, 
this is how they do it. Several folks have brougth that this was 
needed... maybe them can provide exmaples of such apps...

this is the same issue that you brought up in...

> 4.2.  Context Forking
>
>    It has been asserted that it will be important for future ULPs, in
>    particular, future transport protocols, to be able to control which
>    locator pairs are used for different communication.  For instance,
> dmm> sort of violates the property that ULIDs appear to be
> dmm> locators to the ULPs. What are the implications of
> dmm> exposing the ULID/Locator mapping to the ULPs or other
> dmm> applications that use the shim6 service?

...

>
> 4.  Protocol Overview
>
...
>    The shim6 protocol operates in several phases over time.  The
>    following sequence illustrates the concepts:
>
>
>    o  An application on host A decides to contact B using some upper-
>       layer protocol.  This results in the ULP on A sending packets to
>       B. We call this the initial contact.  Assuming the IP addresses
>       selected by Default Address Selection [12] and its extensions 
> [13]
>       work, then there is no action by the shim at this point in time.
>       Any shim context establishment can be deferred until later.
>
> dmm> inconsistent use of Host X and X to refer to the same
> dmm> thing. scan the entire doc for this.
>

i am not sure about this....

we use Host A and host B and then we simply use A and B in order to 
make the reading less loaded...

do you think it is unclear or a matter of style?
...
> 7.  Establishing ULID-Pair Contexts
>

>
>    In all the cases the result is that the peer without state receives 
> a
>    shim message for which it has to context for the context tag.
>
> dmm> BTW, inconsistent use of shim v. shim6
>

shim is used as the generic concept of a middle layer and shim6 is used 
as the specific implementation of a shim described in this document. 
These two terms should be used like this consistently in the whole 
docuemnt, makes sense?
>
...
>
> 7.6.  Context confusion
>
>    Since each end might garbage collect the context state we can have
>    the case when one end has retained the context state and tries to 
> use
>    it, while the other end has lost the state.  We discussed this in 
> the
>    previous section on recovery.  But for the same reasons, when one
>    host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
>    other end might end up allocating that context tag as CT(local) for
>    another ULID pair, e.g., <A3, B1> between the same hosts.  In this
>    case we can not use the recovery mechanisms since there needs to be
>    separate context tags for the two ULID pairs.
>
>    This type of "confusion" can be observed in two cases (assuming it 
> is
>    A that has retained the state and B has dropped it):
>
>    o  B decides to create a context for ULID pair <A3, B1>, and
>       allocates X as its context tag for this, and sends an I1 to A.
>
>
>
>
>
> Nordmark & Bagnulo      Expires November 16, 2006              [Page 
> 58]
> 
> Internet-Draft               Shim6 Protocol                     May 
> 2006
>
>
>    o  A decides to create a context for ULID pair <A3, B1>, and starts
>       the exchange by sending I1 to B. When B receives the I2 message,
>       it allocates X as the context tag for this context.
>
>    In both cases, A can detect that B has allocated X for ULID pair 
> <A3,
>    B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
>    Thus A can detect that B must have lost the context for <A1, B1>.
>
>    The confusion can be detected when I2/I2bis/R2 is received since we
>    require that those messages MUST include a sufficiently large set of
>    locators in a Locator List option that the peer can determine 
> whether
>    or not two contexts have the same host as the peer by comparing if
>    there is any common locators in Ls(peer).
>
> dmm> not really sure how this works. Is it not possible to have
> dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty
> dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing
> dmm> locator sets for peer)? Or is the "sufficiently slowly
> dmm> changing locator sets" assumption operative here?
>

the assumption here is that there is no situation of merging hosts, 
meaning that if two contexts are initiated with a disjoint set of 
locators, they will remain disjoint during the lifetiem of the context, 
and the situation where two contexts have disjoint sets and then later 
on one of them adds new locators that interject with another previously 
disjoint context is not supported. This is what the above assumption is 
expressing... makes sense?

>    The requirement is that the old context which used the context tag
>    MUST be removed; it can no longer be used to send packets.  Thus A
>    would forcibly remove the context state for <A1, B1, X>, so that it
>    can accept the new context for <A3, B1, X>.  An implementation MAY
>    re-create a context to replace the one that was removed; in this 
> case
>    for <A1, B1>.  The normal I1, R1, I2, R2 establishment exchange 
> would
>    then pick unique context tags for that replacement context.  This 
> re-
>    creation is OPTIONAL, but might be useful when there is ULP
>    communication which is using the ULID pair whose context was 
> removed.
>
> dmm> what happens if an "old" I1 was floating around and gets
> dmm> there before the "new" I1 and still within I1_TIMEOUT?
>

I1 new and I1 old are supposed to be equal, right? so if the first one 
arrives first than the second it shouldn't matter i guess...
...
>
>
> 7.20.  Receiving I2bis messages and sending R2 messages
>
>    A host MUST silently discard any received I2bis messages that do not
>    satisfy all of the following validity checks in addition to those
>    specified in Section 12.2:
>
>    o  The Hdr Ext Len field is at least 3, i.e., the length is at least
>       32 octets.
>
>    Upon the reception of an I2bis message, the host extracts the ULID
>    pair and the Forked Instance identifier from the message.  If there
>    is no ULID-pair option, then the ULID pair is taken from the source
>    and destination fields in the IPv6 header.  If there is no FII 
> option
>    in the message, then the FII value is taken to be zero.
>
> dmm> is there a way to get a I2bis with no ULID-pair option but
> dmm> with a (non-zero) FII option? If so, which case is that? If not,
> dmm> what does the host do if it receives that?

both scenarios are supported
the packet can have a ULID option or not and may have a FII option or 
not. all 4 combination are possible...

...
16.  Security Considerations

>
>    o  Every control message of the shim6 protocol, past the context
>       establishment, carry the context tag assigned to the particular
>       context.  This implies that an attacker needs to discover that
>       context tag before being able to spoof any shim6 control message.
>       Such discovery probably requires to be along the path in order to
>       be sniff the context tag value.  The result is that through this
>       technique, the shim6 protocol is protected against off-path
>       attackers.
>
> dmm> why can't I just search the 2^47 space? I suppose an
> dmm> implementation will detect this.
>

we haven't considered the possibility of this attack
the attack that the protocol is protected (sort of) is a memory 
consuption doS attack, in which the attacker generates many shim6 
context in order to exaust the memory of the victim. the protection 
against this attack is that a 4 way handshake is required to establish 
the shim6 context. This implies that the attacker needs to spend 
additional resources in order to launch the attack, these resourses 
would also be needed to launch the CT exahustion attack that you 
describe, do you think this would be enough protection for this case?

thanks again for your careful review...

marcelo

Delivery-date: Sun, 22 Oct 2006 23:27:20 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}
Date: Mon, 23 Oct 2006 01:04:19 +0200
To: Deguang Le <[email-masked]>

Hi Deguang,

sorry for the late reply...

El 12/10/2006, a las 22:59, Deguang Le escribió:

> Thank you very much for your detailed explanations. And I find that 
> the similar statements are presented in Page 113. However, I still can 
> not understand well why we need the "synchronization". :-)
>
> At first, I can not understand what the "synchronization" means 
> exactly.
> To my understanding of your statements. I guess that the
> "synchronization" is a mechanism through which the communicating SHIM6
> hosts can know what the current locator set is, because the 
> communicating SHIM6 host don't know what the current locator set is. 
> Right? :-)
>
i am not sure what do you mean here...

two shim hosts would end up out of synch in the case where a host A has 
a locator set LsA but the host B thinks that A has a locator set LsA* 
which differs from LsA. In this case since A sends incremental updates, 
they will never get in sync again. In the atomic approach, eachg update 
contains all the locator set, so in the case this happens, it would be 
corrected upon the recepntion of the newest UPDATe message, so the out 
of sync problem is more easily dealt with

hope this helps.

regards, marcelo

> If my understanding is correct, I however don't understand why both 
> SHIM6 hosts don't have the same idea about what the current locator 
> set is.
> I think the current locator set is in the SHIM6 context, in other 
> words, each SHIM6 context has (or keep) a current locator set. If the 
> SHIM6 context have been established, the SHIM6 host can obviously know 
> what the current locator set is through the SHIM6 context, which is 
> identified by the context tag, because both SHIM6 host can know the 
> context tag. Right? :-)
>
>
>
>>> If my above issue is reasonable, do you think it is possible to 
>>> define
>>> two new separate options (e.g. Locator Addtion option and Locator
>>> Deletion option) for adding a new locator to the locator set on a 
>>> SHIM6
>>> context and for deleting a failured locator from the locator set on a
>>> SHIM6 context.
>>>
>> see above...
>>>>> If the above two examples belong to the "locator change" 
>>>>> situation,  then I would like to know if a SHIM6 host must (or can 
>>>>> or need to)  send the Locator Request message with Locator List 
>>>>> option to its peers  when the SHIM6 host is assigned a new usable 
>>>>> locator at some interface  of the SHIM6 host or when the SHIM6 
>>>>> host finds one of its locators is  unusable or failure.
>>>>
>>>> but this would be up to the host to decide based in its local 
>>>> policy  rather than a protocol issue imho
>>>
>>> You are right, and I know what you mean. But, I'd only like to know,
>>> from the functionality point of view, if the Update Request message 
>>> with
>>> Locator List option "CAN" be used for this purpose when the above two
>>> situations occur. :-)
>>> From the your following explanations, I think you agree the Update
>>> Request message with Locator List option "CAN" do this.
>>>
>> absolutely, this is possible and a shim6 host can use it in the way 
>> you propose
>>>
>>>> I mean if a host has a new locator it can either add it to all of 
>>>> its  established contexts, or to some of them or none of them 
>>>> depending of  local considerations. Moreover, a host does not need 
>>>> to add all its  locator to all its shim contexts. for instance a 
>>>> host could have a set  of locators tha it uses for certain 
>>>> communications (e.g. communications  within its own site) and some 
>>>> other set of locators that it uses for  other communications (e.g. 
>>>> intersite communications) All these cases  are perfectly ok and the 
>>>> spec supports any behaviour that the host  decides to choose
>>>> A similar consideration applies to the case where the host looses 
>>>> on  locator. Depending on the situation it can either rmove from 
>>>> the  locator set using an Update message or it can mark it as 
>>>> broken using  the preference option or it can even do nothing and 
>>>> the peer will  determine that the locator pairs contianing this 
>>>> locator are  unreachable and will not use them. All these 
>>>> approaches are possibel  and they are supported in the spec.
>>>> So, i am not sure we need to add additional constraints on how ths  
>>>> needs to be used, what do you think?
>>>
>>>
>>> Thank you again, I think your answer confirms my understanding.
>>>
>>> This draft specifies the messages, which are used for multihoming, 
>>> but
>>> it does not clearly present (or explain) if these specifications 
>>> could
>>> be appled for mobilty usage.
>> right, but this is a multihoming solution.... whether this can or not 
>> be used for mobility is another issue and i think it is explicitly 
>> out of the scope of the wg (see the charter)
>
> Yes, you are right. I know SHIM6 is currently for multihoming 
> solution, nor for mobility, and multihoming related issues are mainly 
> discussed in SHIM wg. Since mobility and multihoming have some commen 
> features, and mobility will be ubiquitous on the future Internet, we 
> also need to investiages the possible applications in mobile 
> environments (like the drafts: draft-bagnulo-shim6-mip-00 and 
> draft-ietf-shim6-applicability-01 ), even the potential of mobility 
> support. :-)
>
> Cheers,
> Deguang
>
>
>
>> However, the shim6 protocol can work with mobility protocolos like 
>> MIP and their interaction is detailed in the applibility statement 
>> draft
>
>
>>>
>>> So, the reasion why I ask these questions and make these comments is
>>> that I am not sure if SHIM6 can be used in the mobile environments 
>>> where
>>> a host may change its attachment/location to Internet, namely change 
>>> the
>>> locator (including locator additon and locator deletion).
>>>
>>> In fact, the above two examples I described are exactly the 
>>> situations
>>> that appear in the mobile environments. To my understanding, the
>>> specified locator update messages also can be used for mobility
>>> scenario. Now your answer confirms my understanding. Right?
>>>
>> i think you could, but as i mention this is explicitly out of the 
>> scope of the wg
>> Regards, marcelo
>>>
>>>> Regards, marcelo
>>>>
>>>>>
>>>>> Cheers,
>>>>> Deguang
>>>>>
>>>>>
>>>>> Geoff Huston schrieb:
>>>>>
>>>>>> Hi,
>>>>>> This note starts the WG Last Call for comments on the three 
>>>>>> "base"  Shim6 documents:
>>>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>>>> protocol"
>>>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses 
>>>>>> (HBA)"
>>>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>>>> Locator  Pair                                        Exploration 
>>>>>> Protocol for  IPv6
>>>>>>                                        Multihoming"
>>>>>> They can be found at:
>>>>>>    
>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>>>> detection-06.txt
>>>>>> Please review the documents carefully, and send your feedback to 
>>>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>>>> that  these documents
>>>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>>>> Standards.
>>>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>>>> October 2006 at 0800,  UTC+10
>>>>>>   Thanks,
>>>>>>         Geoff & Kurtis
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
>

Delivery-date: Sun, 22 Oct 2006 23:26:49 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {2}
Date: Mon, 23 Oct 2006 01:09:44 +0200
To: Deguang Le <[email-masked]>

El 13/10/2006, a las 21:40, Deguang Le escribió:

> Thank you very much!
> I think I can understand the situation you described, namely SHIM6  
> works together with MIPv6 and the SHIM6 of the MN uses some HoA as the  
> current locator no matter the MN is attaching the correspondent home  
> network or not. Right? ^-^

no, it just means that the HoA is reachable even if the node is not  
located in the home network, because the HA will forward the messages  
to it.

>
> Base on this situation, your statements are right. However, I think,  
> on one hand, the your described reachability of HoA is achieved  
> through MIP mechanism not SHIM6 itself, on the other hand, although  
> the MIP is appled together with SHIM6, it is still possible that the  
> HoA may be unusable due to the failure of home link or home agent.  
> Therefore, we still could not ensure that the HoA is always reachable.
>

right, but this can also happen to the CoA so both the CoA and the HoA  
may not be reachable because of an outage

> In fact, my understanding about the criterion of choosing a HoA as the
> current locator has some different to yours. I think the choice of
> current locator for a shim6 host depends on if the locator (no matter
> HoA or CoA) is currently associated with a interface of shim6 host and
> is active. Only those active HoAs, which are associated with the shim6  
> host's interfaces, can be chosen for current locator. For example, if  
> the SHIM6 host does not attach to a home network (link), then the  
> SHIM6 protocol of this host should not choose the corresponding HoA as  
> the current locator. This is the reason why I don't think the HoA is  
> the more stable address. right?

no
the CoA is only valid when the MN is located at the visited network.  
once the MN leaves the visted network, the CoA is no loger associated  
with it. The HoA is associated with the MN even if the MN is not  
located in the home netwrok. In this sense, it is expected that the HoA  
will be a more stable address than the CoA, meaning that the HoA will  
be a valid locator for a longer period than the CoA which validity  
period is determined by the time spent in the visited network.

This is independently of how you select your preferred locator.

Regards, marcelo

> :-)
>
> Have a nice weekend!
> Cheers,
> Deguang
>
>
>>>>>  I think it is better if this draft could provides some special   
>>>>> situations about them. Morever, I also can not understand how the   
>>>>> TEMPORARY can be used to distinguish them.
>>>>>
>>>> The usage would be that it will include the Temporary flag when   
>>>> conveying CoA information in the locator set.
>>>
>>>
>>> As my above statements, I think it is not suitable to tag the CoA as
>>> Temporary. Right? :-)
>>>
>> see above
>>>> Do you think that additional text is required to explain this?
>>>
>>> Yes, I think these flags are very important in order to put the  
>>> Locator
>>> Preference option in real use, we need to formulate these flags'
>>> functions and their usage (e.g. applied situations) more clearly.
>>>
>> I am ok with addin additional text for the broken flag since there is  
>> no text describing it... i am willing to include additional text on  
>> the temporary flag, but not sure what to include there though...
>> Regards, marcelo
>>> With best regards,
>>> Deguang
>>>
>>>
>>>> Regards, marcelo
>>>>
>>>>> Cheers,
>>>>> Deguang
>>>>>
>>>>>> Geoff Huston schrieb:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> This note starts the WG Last Call for comments on the three  
>>>>>>> "base"  Shim6 documents:
>>>>>>>
>>>>>>>
>>>>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim   
>>>>>>> protocol"
>>>>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses  
>>>>>>> (HBA)"
>>>>>>>
>>>>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and  
>>>>>>> Locator  Pair                                        Exploration  
>>>>>>> Protocol for  IPv6
>>>>>>>                                        Multihoming"
>>>>>>>
>>>>>>> They can be found at:
>>>>>>>     
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto 
>>>>>>> -05.txt
>>>>>>>     
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>>>>      
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-  
>>>>>>> detection-06.txt
>>>>>>>
>>>>>>> Please review the documents carefully, and send your feedback to  
>>>>>>> the  SHIM6 list.  Please also indicate whether or not you  
>>>>>>> believe that  these documents
>>>>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>>>>>  Standards.
>>>>>>>
>>>>>>> This Working Group Last Call will end in two weeks, on the 12th   
>>>>>>> October 2006 at 0800,  UTC+10
>>>>>>>
>>>>>>>
>>>>>>>   Thanks,
>>>>>>>
>>>>>>>
>>>>>>>         Geoff & Kurtis
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>

Delivery-date: Sun, 22 Oct 2006 23:26:19 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {3}
Date: Mon, 23 Oct 2006 00:53:16 +0200
To: Deguang Le <[email-masked]>

Hi Deguang,

El 15/10/2006, a las 15:24, Deguang Le escribió:

> Hi all,
> a slight comment on the Context Tag...
>
> -Page50
>    o  The context tag used to transmit control messages and payload
>       extension headers - allocated by the peer; CT(peer)
> -Page51
>    o  The context to expect in received control messages and payload
>       extension headers - allocated by the local host; CT(local)
>
> In page 50 and 51, two parameters, namely CT(peer) and CT(local), are 
> defined for each ULID-pair context. right?
>
> However, in page 13, the terminology of CT is given as follows:
>    Context tag         Each end of the context allocates a context tag
>                        for the context.  This is used to uniquely
>                        associate both received control packets and
>                        payload extension headers as belonging to the
>                        context.
>
> Based on my understanding of above CT terminology, for a given 
> context, there is only "A" unique context tag used to identify the 
> context (i.e. the ULID-pair context, right?).
>

no, the above terminology states that _each_ end of the context 
allocates one context tag. since there are two ends in a shim context, 
this sums two context tags, right? CT(peer) and CT(local)

Regards, marcelo

> Therfore, I am confused why each ULID-pair context needs these "TWO" 
> context tags: CT(peer) and CT(local)? Are the CT(peer) and the 
> CT(local) the same thing (or are they the same 47-bit number?)in 
> essence?
>
>
> Have a nice weekend!
> Cheers,
> Deguang
>
>
>
>
>

Delivery-date: Sun, 22 Oct 2006 20:33:38 +0000
Date: Sun, 22 Oct 2006 23:30:56 +0300
From: Jari Arkko <[email-masked]>
To: Deguang Le <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>,  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {2}

Deguang Le wrote:
> -Page8
>    SHIM6 needs to avoid sending packets concurrently over multiple
>    paths, ...
>
> to
>
> -Page8
>    SHIM6 needs to avoid sending packets, which belong to the same
> transport connection (or the same context?), concurrently over multiple
>    paths, ...
This is more accurate, yes. I will change the explanation
as you requested. Note, however, that the failure
detection mechanism is limited to finding and
using a single address pair at a time. It would
be possible to have a protocol extension that
can track multiple pairs, perform load balancing,
etc. However, this will have to be in future
documents. I will make that clear in the document,
too.

--Jari

Delivery-date: Sun, 22 Oct 2006 08:09:47 +0000
Date: Sun, 22 Oct 2006 18:04:22 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Proposed Agenda for IETF 67 (Update 2)
Cc: kurt Erik Lindqvist <[email-masked]>, Shinta Sugimoto <[email-masked]>

Site Multihoming by IPv6 Intermediation WG (SHIM6)
IETF 67, San Diego

Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
=============================

CHAIRS: Geoff Huston <[email-masked]> 
        Kurtis Lindqvist <[email-masked]> 

AGENDA:

 1) Administriva                                             5 minutes

   - Mailing list: http://ops.ietf.org/lists/shim6/
   - Scribe?
   - Blue Sheets
   - Agenda Bashing
   
 2) Last Call Review of "base specification" document set    85 minutes
 
    1. Level 3 multihoming shim protocol
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
 
    2. Hash Based Addresses (HBA)
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt
 
    3. Failure Detection and Locator Pair Exploration Protocol for IPv6
       Multihoming
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt

 3) Shim6 API Draft Update                                   10 minutes
    Shinta Sugimoto
    http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-00.txt
   
 4) Final Report for SHIM Implementation.                    15 minutes
    Kunwoo Park, SNU

 5) WG Direction
 
     Chairs                                                   5 minutes 

Delivery-date: Fri, 20 Oct 2006 06:28:29 +0000
Date: Fri, 20 Oct 2006 15:38:03 +1000
To: Shinta Sugimoto <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Proposed Agenda for IETF 67 (Update 1)
Cc: [email-masked], kurt Erik Lindqvist <[email-masked]>

of course - thank you for this

At 03:29 PM 20/10/2006, Shinta Sugimoto wrote:
>Hello Geoff,
>
>Could you please add one item?
>
>Since the last IETF meeting, we have updated the multihome shim API
>draft according to some reviews made.  So we appreciate if we could
>inform the changes made.  5-10 minutes should be enough for the
>presentation.
>
>Thank you very much.
>
>Regards,
>Shinta
>
>On Fri, 20 Oct 2006 15:13:02 +1000
>Geoff Huston <[email-masked]> wrote:
>
> > 1 - updated hba draft version
> > 2 - added implementation report
> >
> > Are there any other agenda requests?
> >
> > thanks,
> >
> >     Geoff
> >
> >
> >
> > Site Multihoming by IPv6 Intermediation WG (SHIM6)
> > IETF 67, San Diego
> >
> > Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
> > =============================
> >
> > CHAIRS: Geoff Huston <[email-masked]>
> >          Kurtis Lindqvist <[email-masked]>
> >
> >
> > AGENDA:
> >
> >   1) Administriva                                             5 minutes
> >
> >     - Mailing list: http://ops.ietf.org/lists/shim6/
> >     - Scribe?
> >     - Blue Sheets
> >     - Agenda Bashing
> >
> >   2) Last Call Review of "base specification" document set     95 minutes
> >
> >      1. Level 3 multihoming shim protocol
> >         http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
> >
> >      2. Hash Based Addresses (HBA)
> >         http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt
> >
> >      3. Failure Detection and Locator Pair Exploration Protocol for IPv6
> >         Multihoming
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
> >
> >
> >   3) Final Report for SHIM Implementation.                   15 minutes
> >       Kunwoo Park, SNU
> >
> >
> >   4) WG Direction
> >
> >       Chairs                                                   5 minutes

Delivery-date: Fri, 20 Oct 2006 05:29:57 +0000
Date: Fri, 20 Oct 2006 14:29:22 +0900
From: Shinta Sugimoto <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: Re: Proposed Agenda for IETF 67 (Update 1)
Cc: [email-masked], kurt Erik Lindqvist <[email-masked]>

Hello Geoff,

Could you please add one item?

Since the last IETF meeting, we have updated the multihome shim API
draft according to some reviews made.  So we appreciate if we could
inform the changes made.  5-10 minutes should be enough for the
presentation.

Thank you very much.

Regards,
Shinta

On Fri, 20 Oct 2006 15:13:02 +1000
Geoff Huston <[email-masked]> wrote:

> 1 - updated hba draft version
> 2 - added implementation report
> 
> Are there any other agenda requests?
> 
> thanks,
> 
>     Geoff
> 
> 
> 
> Site Multihoming by IPv6 Intermediation WG (SHIM6)
> IETF 67, San Diego
> 
> Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
> =============================
> 
> CHAIRS: Geoff Huston <[email-masked]>
>          Kurtis Lindqvist <[email-masked]>
> 
> 
> AGENDA:
> 
>   1) Administriva                                             5 minutes
> 
>     - Mailing list: http://ops.ietf.org/lists/shim6/
>     - Scribe?
>     - Blue Sheets
>     - Agenda Bashing
> 
>   2) Last Call Review of "base specification" document set     95 minutes
> 
>      1. Level 3 multihoming shim protocol
>         http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
> 
>      2. Hash Based Addresses (HBA)
>         http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt
> 
>      3. Failure Detection and Locator Pair Exploration Protocol for IPv6
>         Multihoming
>         http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
> 
> 
>   3) Final Report for SHIM Implementation.                   15 minutes
>       Kunwoo Park, SNU
> 
> 
>   4) WG Direction
> 
>       Chairs                                                   5 minutes

Delivery-date: Fri, 20 Oct 2006 05:13:44 +0000
Date: Fri, 20 Oct 2006 15:13:02 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Proposed Agenda for IETF 67 (Update 1)
Cc: kurt Erik Lindqvist <[email-masked]>

1 - updated hba draft version
2 - added implementation report

Are there any other agenda requests?

thanks,

    Geoff

Site Multihoming by IPv6 Intermediation WG (SHIM6)
IETF 67, San Diego

Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
=============================

CHAIRS: Geoff Huston <[email-masked]>
         Kurtis Lindqvist <[email-masked]>

AGENDA:

  1) Administriva                                             5 minutes

    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing

  2) Last Call Review of "base specification" document set     95 minutes

     1. Level 3 multihoming shim protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

     2. Hash Based Addresses (HBA)
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt

     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
        Multihoming
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt

  3) Final Report for SHIM Implementation.                   15 minutes
      Kunwoo Park, SNU

  4) WG Direction

      Chairs                                                   5 minutes

Delivery-date: Fri, 20 Oct 2006 05:11:50 +0000
Date: Fri, 20 Oct 2006 15:09:30 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Proposed Agenda for IETF 67
Cc: kurt Erik Lindqvist <[email-masked]>

Update:

hba-02 has just been published

   thanks,

    Geoff

At 05:49 AM 20/10/2006, Geoff Huston wrote:
>Folks,
>
>Here's the proposed agenda for the IETF 67 meeting
>
>Thanks,
>
>    Geoff & Kurtis
>
>------------------------------------
>
>Site Multihoming by IPv6 Intermediation WG (SHIM6)
>IETF 67, San Diego
>
>Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
>=============================
>
>CHAIRS: Geoff Huston <[email-masked]>
>         Kurtis Lindqvist <[email-masked]>
>
>
>AGENDA:
>
>  1) Administriva                                             5 minutes
>
>    - Mailing list: http://ops.ietf.org/lists/shim6/
>    - Scribe?
>    - Blue Sheets
>    - Agenda Bashing
>
>  2) Last Call Review of "base specification" document set    110 minutes
>
>     1. Level 3 multihoming shim protocol
>        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>
>     2. Hash Based Addresses (HBA)
>        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>
>     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
>        Multihoming
> 
>http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
>
>
>
>  3) WG Direction
>
>      Chairs                                                   5 minutes

Delivery-date: Thu, 19 Oct 2006 19:51:05 +0000
Date: Fri, 20 Oct 2006 05:49:57 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Proposed Agenda for IETF 67
Cc: kurt Erik Lindqvist <[email-masked]>

Folks,

Here's the proposed agenda for the IETF 67 meeting

Thanks,

   Geoff & Kurtis

------------------------------------

Site Multihoming by IPv6 Intermediation WG (SHIM6)
IETF 67, San Diego

Thursday, November 9, 2006 1300-1500 (Afternoon Session I)
=============================

CHAIRS: Geoff Huston <[email-masked]> 
        Kurtis Lindqvist <[email-masked]> 

AGENDA:

 1) Administriva                                             5 minutes

   - Mailing list: http://ops.ietf.org/lists/shim6/
   - Scribe?
   - Blue Sheets
   - Agenda Bashing
   
 2) Last Call Review of "base specification" document set    110 minutes
 
    1. Level 3 multihoming shim protocol
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
 
    2. Hash Based Addresses (HBA)
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
 
    3. Failure Detection and Locator Pair Exploration Protocol for IPv6
       Multihoming
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt

        
 3) WG Direction
 
     Chairs                                                   5 minutes

Delivery-date: Thu, 19 Oct 2006 19:40:36 +0000
Date: Fri, 20 Oct 2006 05:39:48 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Summary of issues
Cc: kurt Erik Lindqvist <[email-masked]>

Folks,

I reviewed the SHIM6 mailing list archives since IETF 66 in July, and 
generated a summary of what I felt were the issues raised on the 
shim6 document set, and the comments made in response. I hope this is 
of some assistance.

Again, I'd like to request that you please review these documents and 
come prepared to the WG meeting with your review comments.

regards,

     Geoff

----------------------------------------------------------------

Issues

1. Jim Bound - IPSEC

     "the locator pair in the IP header are not used for IPsec 
encyrpt and decrypt as is done today according to IPsec. This is 
using out-of-bound signals to set up IPsec and was specifically 
rejected as a method for IPsec when defining the IPsec architecture 
back in 1995 at IETF Danvers meeting. In addition this type of use of 
IPsec should be verified and supported by the IPsec WG within the IETF."

     Response:

     There is no "out of band" signalling used to set up IPSEC in a 
SHIM6 context. As the shim sits below the IPSEC processing phase in 
the IP stack IPSEC uses conventional IPSEC-related setup and does not 
rely on any form of out-of-band signalling. The IPSEC SA relies on 
the ULID pair.

2. Jim Bound - Use of HBA

     "Recommendation: For now remove HBA and the use of ULID security 
specifying HBA and leave it as work to be completed that avoids this 
IPR problem with CGA.  Suggestion is to simply embed ULIDs within the 
data payload with new option and secure all communications at least 
for now for IP layer communcatiions with IPsec encryption based on 
locator pair. Separating the movement of Shim6 to proposed standard 
from the issue of ULID security using HBA

     Response:

     IPR issues relating to CGA have been clarified to the Working Group

     Jari Arkko: In the IPR discussion a specific problem that was 
raised was the generality of the defensive clause. As you may 
remember, the statement was formulated such that from Ericsson point 
of view anyone can use this technology for free. But only as long as 
the user do not sue Ericsson for some of his own patents (on any field).

     I plan to ask if our IPR department could agree on changing this 
such that it only applies to IETF technology. Based on a private 
discussion with Jim, this removes at least his concern.

     If there were other IPR related concerns, let me know so that I 
can let our IPR department know. I plan to talk to them later this 
week. In particular, input from the various groups that are working 
with Shim6 implementations for open source would be valuable, if they 
have issues that prevent implementation.

     Jari Arkko: I'm sending this e-mail just to let people know that 
when I talked to the Ericsson IPR department there were OK with the 
proposed change that I described on the list earlier. They will 
update the IPR declaration at the IETF site once its clear that the 
WG is otherwise happy with the protocol set.

3. Jim Bound - modular ULID Security

     "treat the security of ULIDs as module (abstractly speaking) for 
SHIM6 where the user or implementer can plug in different 
solutions.  We would abstract out ULID processing for security so 
that multiple solutions could be used.  Each solution would be its 
own IETF draft specification and IETF discussion with close 
collaboration with the IETF Security Area"

     Response:

     Marcelo Bagnulo: A solution based on IPSec requires either pre 
shared keys between all the nodes in the internet or certificates for 
all the nodes of the internet. This is a huge deployment obstacle. So 
this solution does present this problem and needs to be taken into 
account when evaluating different solutions. A solution that does not 
requires this would require less deployment effort. Of course this is 
not the only (or even most important) consideration when evaluating 
alternative solutions but it is indeed an important element.

     The base protocol has support for multiple security mechanisms 
including CGA and HBA but it leaves the door open to other solutions 
to protect the binding [...] we need to standarize at least one of 
the security mechanisms, if not the shim6 protocol is simply useless. 
The current draft proposes two mechanisms the CGA and the HBAs (and 
implementation can implement just one of them).

     Jari Arkko: First, it is customary to require a mandatory to 
implement security mechanism for IETF specs. Without this, there will 
be very little interoperability. But it doesn't rule out pluggable 
security mechanisms, just that one of them has to be mandatory.

     Second, I believe the specs already support the idea of multiple 
mechanisms; the -hba draft allows either HBA, CGA, or HBA/CGA 
addresses. However, I can not see a mandatory to implement (or any 
other comformance statement) in the draft. Perhaps this should be added.

     Third, I think adding new mechanisms is harder than merely 
designing an interface. An extension spec for an alternate security 
mechanism, describing impact to Shim6 control signaling, payload 
protection, security considerations, etc. I am sure we can do it, but 
I am not sure if we need to develop anything new today to support 
such extensions. Even if we did, it is not clear to me that, say, TLS 
and IPsec based mechanisms would be able to use the same interface. 
But one question: do we have a capability negotiation of the used 
security mechanism in the current protocol? Adding this may be prudent.

     Marcelo Bagnulo: well, what we have in the current protocol is 
that the Locator List Option Format has a one octet of Verification 
Method per locator included in the option, so that we can specify the 
mechanism used to validate each of the locators (currently only HBA 
and CGA methods are defined in the draft)

     Ah, I missed that. This may be enough.

4. Marcelo Bagnulo - multiple hash support in the CGAs

     "As I understood most folks thought that it was a good idea to 
enable multiple hash support in the CGAs and that the proposed 
approach for supporting it was acceptable.

     In order to support multiple public Key algorithms, it is enough 
to define a CGA extension that contains the public key algorithm used 
(and maybe the correspondent key) and to use it as an input to the 
hash, rather than encode in address bits. This is so, because a 
downgrading attack using an alternative (weaker) public key function 
is no different than an attack based on finding an alternative public 
key (using the same algorithm). In order to attack a CGA using an 
alternative (weaker) public key algorithm, the attacker needs to find 
a CGA parameter data structure which hash output collides with the 
target CGA. In order to do that the attacks will probably try with 
alternative modifiers rather than try with alternative pubic keys 
(since it is cheaper as the modifier can be any value and its 
generation is simply adding 1 to the previous value).

     So, from this, it results that in order to prevent downgrading 
attacks only the hash function needs to be included in the address 
itself, and other information (including alternative public key 
algorithms) can be included as CGA extensions. So no modifications to 
the draft will be made in order to support alternative public key functions.

WG Last Call: 27 September

     http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
     http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt

Comments on failure-detection - appear to be resolved
             proto - request to include examples of locator change
                     clarification of "BROKEN" in locator Preference Option

             failure detection - clarity issues, technical change suggested

     We can add in the draft that a locator change is either to add new
     locators to the locator set or to remove locators from it.

     Am ok with addin additional text for the broken flag since there 
is no text describing it... i am willing to include additional text 
on the temporary flag, but not sure what to include there though

Resources for SHIM6
     http://www.shim6.org/

Delivery-date: Thu, 19 Oct 2006 19:38:17 +0000
Date: Fri, 20 Oct 2006 05:35:11 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set
Cc: [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]

Folks,

Kurtis and I have talked to our ADs this week, and following this 
discussion we'd like to propose the following for the SHIM6 meeting at IETF 67.

The last call of these document exposed a number of comments about 
specific aspects of these documents, but the last call was not 
clear  enough, in our view to be able to make the call that we have 
rough consensus on passing these documents to the IESG for proposed 
publication of these three documents as Proposed Standards.

What we'd like to propose to the Working Group is to use the IETF 67 
SHIM6 WG meeting for an extended review of the SHIM6 documents and 
clearly identify residual issues that would allow us to make a call 
of WG consensus to proceed to publication.

If there are any reviewers who would like to undertake a presentation 
of the salient points of their review, please let us know. otherwise 
we will be calling for review comments in the meeting and seeing what 
needs to be done to get to a clear point of consensus on these documents.

So we'd like to request WG members to review these documents:

    draft-ietf-shim6-proto
    draft-ietf-shim6-failure-detection
    draft-ietf-shim6-hba

and come to the working group meeting with your comments.

If there are any other suggestions of agenda items, we'd be happy to 
take them on board, but we would like to concentrate on getting these 
documents to a state that we are happy to pass them onto the IESG 
with a call of rough consensus within the WG.

Thanks,

   Kurtis and Geoff

.

At 02:35 PM 27/09/2006, Geoff Huston wrote:
>Hi,
>
>This note starts the WG Last Call for comments on the three "base"
>Shim6 documents:
>
>
>draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
>
>draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>
>draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator Pair
>                                        Exploration Protocol for IPv6
>                                        Multihoming"
>
>They can be found at:
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
> 
>http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
>
>Please review the documents carefully, and send your feedback to the SHIM6
>list.  Please also indicate whether or not you believe that these documents
>are ready to go to the IESG for publication as a set of Proposed Standards.
>
>This Working Group Last Call will end in two weeks, on the 12th October
>2006 at 0800,  UTC+10
>
>
>   Thanks,
>
>
>         Geoff & Kurtis

Delivery-date: Sun, 15 Oct 2006 14:19:21 +0000
Date: Sun, 15 Oct 2006 16:18:29 +0200
From: Deguang Le <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {2}

Hi Iljitsch, all,
Thank you very much!
Please see my comeents in line... :-)

Iljitsch van Beijnum schrieb:

> On 30-sep-2006, at 16:47, Deguang Le wrote:
> 
>> This paragraph presents "SHIM6 needs to avoid sending packets
>> concurrently over multiple path".
> 
> 
>> However, in RFC 3582 - Goals for IPv6 Site-Multihoming Architectures,
>> Load sharing is one of the goals of multihoming.
>> 3.1.2.  Load Sharing
>>    By multihoming, a site should be able to distribute both inbound  and
>>    outbound traffic between multiple transit providers.  This goal is
>>    for concurrent use of the multiple transit providers, not just the
>>    usage of one provider over one interval of time and another  provider
>>    over a different interval.
> 
> 
>> Therfore, I would like to know if this sentence "SHIM6 needs to avoid
>> sending packets concurrently over multiple path" means that SHIM6
>> doesn't support load sharing?
> 
> 
> The text you cite pertains to individual shim contexts. Often, a shim  
> context will be used for a single TCP session, and it's considered  
> suboptimal to have packets belonging to the same TCP session travel  
> through different paths, because this introduces packet reordering  
> which impedes TCP performance.
> 
> However, shim6 still supports load balancing by allowing different  
> contexts to use different addresses, so that part of the contexts  will 
> generate traffic over one path and part of the contexts over  another path.
> 
> Note though, that most traffic will be associated with contexts for  
> which no shim6 address rewriting is active, so load balancing greatly  
> depends on things outside the scope of shim6, such as information in  
> the DNS and routing.

I agree with you.
Based on you comments, in order to avoid the confision, do you think it 
is more precise to revise the follwoing sentence? :-)

-Page8
    SHIM6 needs to avoid sending packets concurrently over multiple
    paths, ...

to

-Page8
    SHIM6 needs to avoid sending packets, which belong to the same 
transport connection (or the same context?), concurrently over multiple
    paths, ...

Cheers,
Deguang

Delivery-date: Sun, 15 Oct 2006 13:26:53 +0000
Date: Sun, 15 Oct 2006 15:24:52 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: comments on draft-ietf-shim6-proto-05.txt {3}

Hi all,
a slight comment on the Context Tag...

-Page50
    o  The context tag used to transmit control messages and payload
       extension headers - allocated by the peer; CT(peer)
-Page51
    o  The context to expect in received control messages and payload
       extension headers - allocated by the local host; CT(local)

In page 50 and 51, two parameters, namely CT(peer) and CT(local), are 
defined for each ULID-pair context. right?

However, in page 13, the terminology of CT is given as follows:
    Context tag         Each end of the context allocates a context tag
                        for the context.  This is used to uniquely
                        associate both received control packets and
                        payload extension headers as belonging to the
                        context.

Based on my understanding of above CT terminology, for a given context, 
there is only "A" unique context tag used to identify the context (i.e. 
the ULID-pair context, right?).

Therfore, I am confused why each ULID-pair context needs these "TWO" 
context tags: CT(peer) and CT(local)? Are the CT(peer) and the CT(local) 
the same thing (or are they the same 47-bit number?)in essence?

Have a nice weekend!
Cheers,
Deguang

Delivery-date: Fri, 13 Oct 2006 19:41:57 +0000
Date: Fri, 13 Oct 2006 21:40:11 +0200
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {2}

marcelo bagnulo braun schrieb:

> 
> El 08/10/2006, a las 17:09, Deguang Le escribió:
> 
>>> agree
>>> basically the usage of the BROKEN flag is intended for when the host  
>>> knows thanks to local information that a locator is temporarily  
>>> unavailbale/unreachable, so it can mark it as such, so that the peer  
>>> doesn't use it for communicating.
>>
>>
>> I agree with you, it is a good way to deal with the temporary failure of
>> locator using the BROKEN flag.
>> However, if the locator is permanently unavailbale/unreachable say due
>> to mobility or rehoming, I think it is not necessary to keep the
>> unavailable locator in the locator set. Right?
>>
> 
> both approaches are possible and i guess that your viewpoint makes more 
> sense
> 
>>> As mentioned in the other email, another option would be to remove 
>>> from  the locator set using a Update message, but i guess this option 
>>> is  cheaper in terms of processing (cheaper security checks)
>>
>>
>> As for security check, I am not familiar with security issue, so I don't
>> know why the Locator Preference option need not verification check. ^-^
>>
>> Does anyone provide some explanations about it? Thank in advance.
>>
> 
> to change the locator set you need to include security information 
> either HBA or CGA. In the HBA case, this is a hash calculation and in 
> the CGA is a public key operation. OTOH, to change the preferences, only 
> a cookie is used, so it is much cheaper. This is so because changing the 
> locator set may result in all types of redirection attacks from off path 
> attacker. However, changing the preferences can only be done by on path 
> attacker and it would result in potentially changing the locator used 
> (if the peer takes into account the preferences). Hence the protection 
> of one operation is less than the other.
Thank you very much for your detailed explanations. :-)

> 
>>>> Besides, the above explanation for "TEMPORARY" is still not clear 
>>>> for  me. What are the more stable addresses and what are the less 
>>>> stable  addresses?
>>>
>>> the goal here is that if the host knows that there are some addresses 
>>>  that may change rapidly, it can mark them as such, so that the peer 
>>> use  more aggresive failure detection mechanisms on that address.
>>
>>
>> I think it is an interesting usage although it is not easy to determine
>> which addresses belong to more stable or less stable. :-)
>>
>>> In the case of MIP a HoA is a more stable address and a CoA is a less 
>>>  stable address
>>
>> In my own veiw, I don't think the HoA is the more stable address and the
>> CoA is the less stable address because the mobile node may stay at any
>> place including the home network or foreign network at any time.
>> For example, a mobile node may access to the Internet through some
>> foreign network, then it may moves between the foreign networks, which
>> are far from the home network. In this case, the HoA may never be usable
>> during the whole communication period. Therefore, we could not regard 
>> the HoA as the more stable address. Right?
>>
> 
> i don't think so...
> 
> the Hoa is always reachable because the Home Agent would forward the 
> packets delivered to the HoA (the performance would be worse though) The 
> CoA is only usable while the node is in the visited network, hence the 
> HoA is much more stable than the CoA even in the scenario that you 
> describe, agree?
> 
Thank you very much!
I think I can understand the situation you described, namely SHIM6 works 
together with MIPv6 and the SHIM6 of the MN uses some HoA as the current 
locator no matter the MN is attaching the correspondent home network or 
not. Right? ^-^

Base on this situation, your statements are right. However, I think, on 
one hand, the your described reachability of HoA is achieved through MIP 
mechanism not SHIM6 itself, on the other hand, although the MIP is 
appled together with SHIM6, it is still possible that the HoA may be 
unusable due to the failure of home link or home agent. Therefore, we 
still could not ensure that the HoA is always reachable.

In fact, my understanding about the criterion of choosing a HoA as the
current locator has some different to yours. I think the choice of
current locator for a shim6 host depends on if the locator (no matter
HoA or CoA) is currently associated with a interface of shim6 host and
is active. Only those active HoAs, which are associated with the shim6 
host's interfaces, can be chosen for current locator. For example, if 
the SHIM6 host does not attach to a home network (link), then the SHIM6 
protocol of this host should not choose the corresponding HoA as the 
current locator. This is the reason why I don't think the HoA is the 
more stable address. right? :-)

Have a nice weekend!
Cheers,
Deguang

>>>>  I think it is better if this draft could provides some special  
>>>> situations about them. Morever, I also can not understand how the  
>>>> TEMPORARY can be used to distinguish them.
>>>>
>>> The usage would be that it will include the Temporary flag when  
>>> conveying CoA information in the locator set.
>>
>>
>> As my above statements, I think it is not suitable to tag the CoA as
>> Temporary. Right? :-)
>>
> see above
> 
> 
>>> Do you think that additional text is required to explain this?
>>
>> Yes, I think these flags are very important in order to put the Locator
>> Preference option in real use, we need to formulate these flags'
>> functions and their usage (e.g. applied situations) more clearly.
>>
> 
> I am ok with addin additional text for the broken flag since there is no 
> text describing it... i am willing to include additional text on the 
> temporary flag, but not sure what to include there though...
> 
> Regards, marcelo
> 
> 
>> With best regards,
>> Deguang
>>
>>
>>> Regards, marcelo
>>>
>>>> Cheers,
>>>> Deguang
>>>>
>>>>> Geoff Huston schrieb:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This note starts the WG Last Call for comments on the three "base" 
>>>>>>  Shim6 documents:
>>>>>>
>>>>>>
>>>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>>>> protocol"
>>>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>>>>
>>>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>>>> Locator  Pair                                        Exploration 
>>>>>> Protocol for  IPv6
>>>>>>                                        Multihoming"
>>>>>>
>>>>>> They can be found at:
>>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>>>> detection-06.txt
>>>>>>
>>>>>> Please review the documents carefully, and send your feedback to 
>>>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>>>> that  these documents
>>>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>>>> Standards.
>>>>>>
>>>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>>>> October 2006 at 0800,  UTC+10
>>>>>>
>>>>>>
>>>>>>   Thanks,
>>>>>>
>>>>>>
>>>>>>         Geoff & Kurtis
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
> 

Delivery-date: Thu, 12 Oct 2006 22:29:28 +0000
Content-class: urn:content-classes:message
Subject: comments on draft-ietf-shim6-failure-detection-06.txt {4}
Date: Thu, 12 Oct 2006 15:28:30 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: <[email-masked]>

I reviewed the failure detection draft today and have the following
comments.

Clarity issues
==============
1. The state machine could be clarified a bit.  There is an
"Operational" state but associated with this state are two timers, and
depending on which timers are active at a given time, there are actually
three substates, which one might call "Idle" (no timers running),
"Operational-In" (KeepAlive running), and "Operational-Out" (Send
running).  The draft implies that Send and Keepalive are not running
simultaneously ("Upon the reception of a payload packet in the
Operational state, the node starts the Keepalive timer if it is not yet
running, and stops the Send timer if it was running."); this implies
that a bidirectional data flow will (conceptually) be toggling
continuously between Operational-In and Operational-Out.  It could be
better clarified that if a host moves to a quiescent state upon sending
a single keepalive message, unless woken up by either its own send event
or the reception of another peer data packet.     

It might be worth considering to break out the Operational state into
substates to see what the implications are for the state machine, and
only then decide whether one wants to collapse the substates into a
single state.  Perhaps this has already been considered and rejected
(I'm new to this discussion). 

2.  The linkage between these failure detection mechanisms and return
routability checks is fuzzy.  If REAP detects through probing that a
locator pair works, does this suffice for reachability, or does separate
shim6 process need to send Update Request?  The last paragraph of 3.3
seems to imply that shim6 must separately verify return routability.
But the shim6 draft says that the Probe message exchange handles this
routability check.    This really ought to be clarified somewhere in
this draft.

3. There seems to be a mismatch with the shim6-proto draft, where it
says that there are "Probe Option", "Reachability Option", and "Payload
Reception Report Option" TLVs defined in this draft.  I couldn't find
any such Option definitions.

4.   There could be more clarity in the terminology for address pairs.
The protocol draft talks of ULID-pairs and current locator pair, while
this draft talks about primary address pair and current address pair.
Second, it probably needs to be distinguished that there is an inbound
address pair and an outbound address pair that may be the same or
different.  I suggest to consistently use the terms "ULID-pair",
"outbound locator pair", "inbound locator pair" and possibly to clarify
that when "locator pair" is used without reference to inbound or
outbound, it refers to the case where they are the same pair.

5.  In general, sections 6 and 7 seem drafty to me.  Section 7
(examples) probably should be an appendix, and section 6 should be
expanded into more detailed elements of procedure, such as how to fill
in parameter values and what are the legal values, that do not require
reading section 7 to find the details.

6.  In section 7, examples 4 and 5, where are the keepalives preceding
the 10 second timeout.  Why won't peer A be the one to first have a Send
timeout in example 4?

Suggested technical change
==========================
I disagree with fixing the KeepaliveTimeout to 10 seconds and making the
possible negotiation an area for future study.  I don't see why each
node couldn't set a parameter in the initial exchange that directed a
peer to use a particular timeout value.   There doesn't have to be any
negotiation; each side can configure the KeepaliveTimeout that the peer
must use for setting Keepalive timer, and optionally include the
parameter in the I2, R2, and possibly I2-bis packets.  Send timer can be
aligned with the Keepalive timer interval given to the peer.  The
default (if no such parameter is present) could be 10 seconds.  I
suggest to define the parameter now, as well as instructing
implementations to honor it if they receive such a parameter, and say
that the heuristics for sending it are for further study.
 
Minor
====
title of section 4.2 "Alternate Address Pair Exploration" should
probably be "Full Reachability Exploration" to match other references in
the text to this procedure

in section 3.5, s/multible/multiple

in section 3.4, the acronym "ULID" is used for the first time without
any expansion or reference.

ExploringOK state could have a name that is more indicative of the state
of the exploration, such as InboundOK

In section 6, the explanatory text for each event precedes the numbered,
underlined event definition, and it is somewhat confusing to read
because the numbered lines seem to delineate the sections but they in
fact do not.

- Tom

Delivery-date: Thu, 12 Oct 2006 21:00:37 +0000
Date: Thu, 12 Oct 2006 22:59:43 +0200
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}

marcelo bagnulo braun schrieb:
> 
> El 08/10/2006, a las 17:09, Deguang Le escribió:
> 
>>
>> I don't mean that there are any situation where we could have a locator
>> change and the usage of the Update message wouldn't apply. ^-^
>> I mean: could the usage of the Update message apply in the mobility
>> situation where we could have a locator change? :-)
>>
> 
> i guess so...
> i mean, in the mobility scenario, the host learns a new address from the 
> visited network. This address can be used as a locator for established 
> contexts. The result is that there is a new locator available for the 
> shim context. If the host wants to use the new locator for the 
> estbalished communication, it must add it to the existent locator set 
> and in order to do that, it should use the Update message
> 
> But in any case, imho this falls in the general case where the host 
> learns a new locator and wants to use it in the established contexts 
> (similar to the case where a new prefix is added for a multihomed site)
> 
>>>>  I think it would be better if this draft could provide some 
>>>> examples  (cases) about the locator change in real applications. For 
>>>> examples, I  would like to know if the follwoing cases belong to the 
>>>> "locator  change" situation described in this draft:
>>>> -A SHIM6 host is assigned a new usable locator at some interface of  
>>>> the SHIM6 host.
>>>>
>>> We can add in the draft that a locator change is either to add new  
>>> locators to the locator set or to remove locators from it.
>>>
>>>> -A SHIM6 host finds one of its locators is unusable or failure.
>>>>
>>> Please note that when a host finds that one of its locators is  
>>> temporarily unusable e.g. it is unreachable, or there is a local  
>>> failure, it can use the Update message to inform about the situation 
>>> or  it can simply convey Locator Preference infromation. This lasst 
>>> option  is a cheaper option in terms of processing because of the 
>>> security  checks
>>
>>
>> You are right, I agree with you. However, there still may be the case
>> where the shim6 host determines one of its locators is permanently
>> unusable. I think in this case it is better to remove the unusable
>> locator from the locator set. right? :-)
>>
> 
> yes, this seems the most neat approach
> 
>> By the way, I would like to discuss the efficiency of using the Locator
>> List option for the addition/deletion of locator to/from the locator set
>> further.
>> Because this draft specifies that "ALL" the locators must be carried in
>> the Locator List option (see page42), I think it is not efficient to use
>> the Locator List option in the case where only one locator needs to be
>> add or removed while other locators keep unchanged. I think it is not
>> necessary to update those unchanged locators and repetitively perform
>> locator verification for those unchanged locators each time when only a
>> locator changes. As you said , it is expensive option. Right? :-)
>>
> 
> this issue was discussed during the design and there were two possible 
> approaches: the atomic approach, where each update message contains all 
> the locators and the diferential approach where each message contains 
> the diff from the existent locator set. As you mention the differential 
> approach is more efficient in terms of overhead. The problem with the 
> differential approach is that is more complex because both peers need to 
> be synchronized i.e. both ends need to have the same idea of what the 
> current locator set is. If a message is lost and the synchronization 
> between the peers is lost, then they will end up with different 
> perceptions of what the locator set is. This must be avoided. If we want 
> to avoid this we need to build a reliable mechanism for exchanging the 
> update message and its associated complexity, and also how to deal if 
> the peers end up out of sync. We decided that it was a reasonable 
> tradeoff to use the atomic approach and we have more overhead but less 
> complexity.

Thank you very much for your detailed explanations. And I find that the 
similar statements are presented in Page 113. However, I still can not 
understand well why we need the "synchronization". :-)

At first, I can not understand what the "synchronization" means exactly.
To my understanding of your statements. I guess that the
"synchronization" is a mechanism through which the communicating SHIM6
hosts can know what the current locator set is, because the 
communicating SHIM6 host don't know what the current locator set is. 
Right? :-)

If my understanding is correct, I however don't understand why both 
SHIM6 hosts don't have the same idea about what the current locator set is.
I think the current locator set is in the SHIM6 context, in other words, 
each SHIM6 context has (or keep) a current locator set. If the SHIM6 
context have been established, the SHIM6 host can obviously know what 
the current locator set is through the SHIM6 context, which is 
identified by the context tag, because both SHIM6 host can know the 
context tag. Right? :-)

> 
>> If my above issue is reasonable, do you think it is possible to define
>> two new separate options (e.g. Locator Addtion option and Locator
>> Deletion option) for adding a new locator to the locator set on a SHIM6
>> context and for deleting a failured locator from the locator set on a
>> SHIM6 context.
>>
> 
> see above...
> 
>>>> If the above two examples belong to the "locator change" situation,  
>>>> then I would like to know if a SHIM6 host must (or can or need to)  
>>>> send the Locator Request message with Locator List option to its 
>>>> peers  when the SHIM6 host is assigned a new usable locator at some 
>>>> interface  of the SHIM6 host or when the SHIM6 host finds one of its 
>>>> locators is  unusable or failure.
>>>
>>> but this would be up to the host to decide based in its local policy  
>>> rather than a protocol issue imho
>>
>> You are right, and I know what you mean. But, I'd only like to know,
>> from the functionality point of view, if the Update Request message with
>> Locator List option "CAN" be used for this purpose when the above two
>> situations occur. :-)
>> From the your following explanations, I think you agree the Update
>> Request message with Locator List option "CAN" do this.
>>
> 
> absolutely, this is possible and a shim6 host can use it in the way you 
> propose
> 
>>
>>> I mean if a host has a new locator it can either add it to all of its 
>>>  established contexts, or to some of them or none of them depending 
>>> of  local considerations. Moreover, a host does not need to add all 
>>> its  locator to all its shim contexts. for instance a host could have 
>>> a set  of locators tha it uses for certain communications (e.g. 
>>> communications  within its own site) and some other set of locators 
>>> that it uses for  other communications (e.g. intersite 
>>> communications) All these cases  are perfectly ok and the spec 
>>> supports any behaviour that the host  decides to choose
>>> A similar consideration applies to the case where the host looses on  
>>> locator. Depending on the situation it can either rmove from the  
>>> locator set using an Update message or it can mark it as broken using 
>>>  the preference option or it can even do nothing and the peer will  
>>> determine that the locator pairs contianing this locator are  
>>> unreachable and will not use them. All these approaches are possibel  
>>> and they are supported in the spec.
>>> So, i am not sure we need to add additional constraints on how ths  
>>> needs to be used, what do you think?
>>
>>
>> Thank you again, I think your answer confirms my understanding.
>>
>> This draft specifies the messages, which are used for multihoming, but
>> it does not clearly present (or explain) if these specifications could
>> be appled for mobilty usage.
> 
> 
> right, but this is a multihoming solution.... whether this can or not be 
> used for mobility is another issue and i think it is explicitly out of 
> the scope of the wg (see the charter)

Yes, you are right. I know SHIM6 is currently for multihoming solution, 
nor for mobility, and multihoming related issues are mainly discussed in 
SHIM wg. Since mobility and multihoming have some commen features, and 
mobility will be ubiquitous on the future Internet, we also need to 
investiages the possible applications in mobile environments (like the 
drafts: draft-bagnulo-shim6-mip-00 and draft-ietf-shim6-applicability-01 
), even the potential of mobility support. :-)

Cheers,
Deguang

> 
> However, the shim6 protocol can work with mobility protocolos like MIP 
> and their interaction is detailed in the applibility statement draft

> 
>>
>> So, the reasion why I ask these questions and make these comments is
>> that I am not sure if SHIM6 can be used in the mobile environments where
>> a host may change its attachment/location to Internet, namely change the
>> locator (including locator additon and locator deletion).
>>
>> In fact, the above two examples I described are exactly the situations
>> that appear in the mobile environments. To my understanding, the
>> specified locator update messages also can be used for mobility
>> scenario. Now your answer confirms my understanding. Right?
>>
> 
> i think you could, but as i mention this is explicitly out of the scope 
> of the wg
> 
> Regards, marcelo
> 
> 
>>
>>> Regards, marcelo
>>>
>>>>
>>>> Cheers,
>>>> Deguang
>>>>
>>>>
>>>> Geoff Huston schrieb:
>>>>
>>>>> Hi,
>>>>> This note starts the WG Last Call for comments on the three "base"  
>>>>> Shim6 documents:
>>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>>> protocol"
>>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>>> Locator  Pair                                        Exploration 
>>>>> Protocol for  IPv6
>>>>>                                        Multihoming"
>>>>> They can be found at:
>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>>> detection-06.txt
>>>>> Please review the documents carefully, and send your feedback to 
>>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>>> that  these documents
>>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>>> Standards.
>>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>>> October 2006 at 0800,  UTC+10
>>>>>   Thanks,
>>>>>         Geoff & Kurtis
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
> 

Delivery-date: Thu, 12 Oct 2006 20:41:42 +0000
Date: Thu, 12 Oct 2006 22:39:45 +0200
From: Deguang Le <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}

Hi Jari, all,
Thank you very much for your comments. :-)
Marcelo also provided a similar comments on this issue.
Please see my responses to your comments in Marcelo mail. :-)

Cheers,
Deguang

Jari Arkko schrieb:
> If I understood this correctly, the request
> was to provide a "diff" update as opposed
> to "here's the new list" message that we
> have now:
> 
>>You are right, I agree with you. However, there still may be the case
>>where the shim6 host determines one of its locators is permanently
>>unusable. I think in this case it is better to remove the unusable
>>locator from the locator set. right? :-)
>>
>>By the way, I would like to discuss the efficiency of using the Locator
>>List option for the addition/deletion of locator to/from the locator set
>>further.
>>Because this draft specifies that "ALL" the locators must be carried in
>>the Locator List option (see page42), I think it is not efficient to use
>>the Locator List option in the case where only one locator needs to be
>>add or removed while other locators keep unchanged. I think it is not
>>necessary to update those unchanged locators and repetitively perform
>>locator verification for those unchanged locators each time when only a
>>locator changes. As you said , it is expensive option. Right? :-)
>>
>>If my above issue is reasonable, do you think it is possible to define
>>two new separate options (e.g. Locator Addtion option and Locator
>>Deletion option) for adding a new locator to the locator set on a SHIM6
>>context and for deleting a failured locator from the locator set on a
>>SHIM6 context. 
> 
> From a functional standpoint we could use either
> the diff or the complete list approach. However, as
> this was discussed during the protocol design,
> people felt that the latter was a better choice.
> It is true that the diff approach can be more
> efficient in some cases. However, the benefits
> are offset by higher complexity and the risk
> of synchronization failures. Finally, I believe
> that in most cases where the node is truly
> mobile, the number of locators is likely
> relatively small, so the real-world savings
> may not be that big.
> 
> --Jari

Delivery-date: Mon, 09 Oct 2006 13:38:26 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {2}
Date: Mon, 9 Oct 2006 15:38:06 +0200
To: Deguang Le <[email-masked]>

El 08/10/2006, a las 17:09, Deguang Le escribió:
>> agree
>> basically the usage of the BROKEN flag is intended for when the host  
>> knows thanks to local information that a locator is temporarily  
>> unavailbale/unreachable, so it can mark it as such, so that the peer  
>> doesn't use it for communicating.
>
> I agree with you, it is a good way to deal with the temporary failure 
> of
> locator using the BROKEN flag.
> However, if the locator is permanently unavailbale/unreachable say due
> to mobility or rehoming, I think it is not necessary to keep the
> unavailable locator in the locator set. Right?
>

both approaches are possible and i guess that your viewpoint makes more 
sense

>> As mentioned in the other email, another option would be to remove 
>> from  the locator set using a Update message, but i guess this option 
>> is  cheaper in terms of processing (cheaper security checks)
>
> As for security check, I am not familiar with security issue, so I 
> don't
> know why the Locator Preference option need not verification check. ^-^
>
> Does anyone provide some explanations about it? Thank in advance.
>

to change the locator set you need to include security information 
either HBA or CGA. In the HBA case, this is a hash calculation and in 
the CGA is a public key operation. OTOH, to change the preferences, 
only a cookie is used, so it is much cheaper. This is so because 
changing the locator set may result in all types of redirection attacks 
from off path attacker. However, changing the preferences can only be 
done by on path attacker and it would result in potentially changing 
the locator used (if the peer takes into account the preferences). 
Hence the protection of one operation is less than the other.

>>> Besides, the above explanation for "TEMPORARY" is still not clear 
>>> for  me. What are the more stable addresses and what are the less 
>>> stable  addresses?
>> the goal here is that if the host knows that there are some addresses 
>>  that may change rapidly, it can mark them as such, so that the peer 
>> use  more aggresive failure detection mechanisms on that address.
>
> I think it is an interesting usage although it is not easy to determine
> which addresses belong to more stable or less stable. :-)
>
>> In the case of MIP a HoA is a more stable address and a CoA is a less 
>>  stable address
> In my own veiw, I don't think the HoA is the more stable address and 
> the
> CoA is the less stable address because the mobile node may stay at any
> place including the home network or foreign network at any time.
> For example, a mobile node may access to the Internet through some
> foreign network, then it may moves between the foreign networks, which
> are far from the home network. In this case, the HoA may never be 
> usable
> during the whole communication period. Therefore, we could not regard 
> the HoA as the more stable address. Right?
>

i don't think so...

the Hoa is always reachable because the Home Agent would forward the 
packets delivered to the HoA (the performance would be worse though) 
The CoA is only usable while the node is in the visited network, hence 
the HoA is much more stable than the CoA even in the scenario that you 
describe, agree?

>>>  I think it is better if this draft could provides some special  
>>> situations about them. Morever, I also can not understand how the  
>>> TEMPORARY can be used to distinguish them.
>>>
>> The usage would be that it will include the Temporary flag when  
>> conveying CoA information in the locator set.
>
> As my above statements, I think it is not suitable to tag the CoA as
> Temporary. Right? :-)
>
see above

>> Do you think that additional text is required to explain this?
> Yes, I think these flags are very important in order to put the Locator
> Preference option in real use, we need to formulate these flags'
> functions and their usage (e.g. applied situations) more clearly.
>

I am ok with addin additional text for the broken flag since there is 
no text describing it... i am willing to include additional text on the 
temporary flag, but not sure what to include there though...

Regards, marcelo

> With best regards,
> Deguang
>
>
>> Regards, marcelo
>>> Cheers,
>>> Deguang
>>>
>>>> Geoff Huston schrieb:
>>>>
>>>>> Hi,
>>>>>
>>>>> This note starts the WG Last Call for comments on the three "base" 
>>>>>  Shim6 documents:
>>>>>
>>>>>
>>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>>> protocol"
>>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>>>
>>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>>> Locator  Pair                                        Exploration 
>>>>> Protocol for  IPv6
>>>>>                                        Multihoming"
>>>>>
>>>>> They can be found at:
>>>>>    
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>>> detection-06.txt
>>>>>
>>>>> Please review the documents carefully, and send your feedback to 
>>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>>> that  these documents
>>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>>> Standards.
>>>>>
>>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>>> October 2006 at 0800,  UTC+10
>>>>>
>>>>>
>>>>>   Thanks,
>>>>>
>>>>>
>>>>>         Geoff & Kurtis
>>>
>>>
>>>
>
>
>
>

Delivery-date: Mon, 09 Oct 2006 13:28:45 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}
Date: Mon, 9 Oct 2006 15:27:58 +0200
To: Deguang Le <[email-masked]>

El 08/10/2006, a las 17:09, Deguang Le escribió:

>
> I don't mean that there are any situation where we could have a locator
> change and the usage of the Update message wouldn't apply. ^-^
> I mean: could the usage of the Update message apply in the mobility
> situation where we could have a locator change? :-)
>

i guess so...
i mean, in the mobility scenario, the host learns a new address from 
the visited network. This address can be used as a locator for 
established contexts. The result is that there is a new locator 
available for the shim context. If the host wants to use the new 
locator for the estbalished communication, it must add it to the 
existent locator set and in order to do that, it should use the Update 
message

But in any case, imho this falls in the general case where the host 
learns a new locator and wants to use it in the established contexts 
(similar to the case where a new prefix is added for a multihomed site)

>>>  I think it would be better if this draft could provide some 
>>> examples  (cases) about the locator change in real applications. For 
>>> examples, I  would like to know if the follwoing cases belong to the 
>>> "locator  change" situation described in this draft:
>>> -A SHIM6 host is assigned a new usable locator at some interface of  
>>> the SHIM6 host.
>>>
>> We can add in the draft that a locator change is either to add new  
>> locators to the locator set or to remove locators from it.
>>> -A SHIM6 host finds one of its locators is unusable or failure.
>>>
>> Please note that when a host finds that one of its locators is  
>> temporarily unusable e.g. it is unreachable, or there is a local  
>> failure, it can use the Update message to inform about the situation 
>> or  it can simply convey Locator Preference infromation. This lasst 
>> option  is a cheaper option in terms of processing because of the 
>> security  checks
>
> You are right, I agree with you. However, there still may be the case
> where the shim6 host determines one of its locators is permanently
> unusable. I think in this case it is better to remove the unusable
> locator from the locator set. right? :-)
>

yes, this seems the most neat approach

> By the way, I would like to discuss the efficiency of using the Locator
> List option for the addition/deletion of locator to/from the locator 
> set
> further.
> Because this draft specifies that "ALL" the locators must be carried in
> the Locator List option (see page42), I think it is not efficient to 
> use
> the Locator List option in the case where only one locator needs to be
> add or removed while other locators keep unchanged. I think it is not
> necessary to update those unchanged locators and repetitively perform
> locator verification for those unchanged locators each time when only a
> locator changes. As you said , it is expensive option. Right? :-)
>

this issue was discussed during the design and there were two possible 
approaches: the atomic approach, where each update message contains all 
the locators and the diferential approach where each message contains 
the diff from the existent locator set. As you mention the differential 
approach is more efficient in terms of overhead. The problem with the 
differential approach is that is more complex because both peers need 
to be synchronized i.e. both ends need to have the same idea of what 
the current locator set is. If a message is lost and the 
synchronization between the peers is lost, then they will end up with 
different perceptions of what the locator set is. This must be avoided. 
If we want to avoid this we need to build a reliable mechanism for 
exchanging the update message and its associated complexity, and also 
how to deal if the peers end up out of sync. We decided that it was a 
reasonable tradeoff to use the atomic approach and we have more 
overhead but less complexity.

> If my above issue is reasonable, do you think it is possible to define
> two new separate options (e.g. Locator Addtion option and Locator
> Deletion option) for adding a new locator to the locator set on a SHIM6
> context and for deleting a failured locator from the locator set on a
> SHIM6 context.
>

see above...

>>> If the above two examples belong to the "locator change" situation,  
>>> then I would like to know if a SHIM6 host must (or can or need to)  
>>> send the Locator Request message with Locator List option to its 
>>> peers  when the SHIM6 host is assigned a new usable locator at some 
>>> interface  of the SHIM6 host or when the SHIM6 host finds one of its 
>>> locators is  unusable or failure.
>> but this would be up to the host to decide based in its local policy  
>> rather than a protocol issue imho
> You are right, and I know what you mean. But, I'd only like to know,
> from the functionality point of view, if the Update Request message 
> with
> Locator List option "CAN" be used for this purpose when the above two
> situations occur. :-)
> From the your following explanations, I think you agree the Update
> Request message with Locator List option "CAN" do this.
>

absolutely, this is possible and a shim6 host can use it in the way you 
propose

>
>> I mean if a host has a new locator it can either add it to all of its 
>>  established contexts, or to some of them or none of them depending 
>> of  local considerations. Moreover, a host does not need to add all 
>> its  locator to all its shim contexts. for instance a host could have 
>> a set  of locators tha it uses for certain communications (e.g. 
>> communications  within its own site) and some other set of locators 
>> that it uses for  other communications (e.g. intersite 
>> communications) All these cases  are perfectly ok and the spec 
>> supports any behaviour that the host  decides to choose
>> A similar consideration applies to the case where the host looses on  
>> locator. Depending on the situation it can either rmove from the  
>> locator set using an Update message or it can mark it as broken using 
>>  the preference option or it can even do nothing and the peer will  
>> determine that the locator pairs contianing this locator are  
>> unreachable and will not use them. All these approaches are possibel  
>> and they are supported in the spec.
>> So, i am not sure we need to add additional constraints on how ths  
>> needs to be used, what do you think?
>
> Thank you again, I think your answer confirms my understanding.
>
> This draft specifies the messages, which are used for multihoming, but
> it does not clearly present (or explain) if these specifications could
> be appled for mobilty usage.

right, but this is a multihoming solution.... whether this can or not 
be used for mobility is another issue and i think it is explicitly out 
of the scope of the wg (see the charter)

However, the shim6 protocol can work with mobility protocolos like MIP 
and their interaction is detailed in the applibility statement draft

>
> So, the reasion why I ask these questions and make these comments is
> that I am not sure if SHIM6 can be used in the mobile environments 
> where
> a host may change its attachment/location to Internet, namely change 
> the
> locator (including locator additon and locator deletion).
>
> In fact, the above two examples I described are exactly the situations
> that appear in the mobile environments. To my understanding, the
> specified locator update messages also can be used for mobility
> scenario. Now your answer confirms my understanding. Right?
>

i think you could, but as i mention this is explicitly out of the scope 
of the wg

Regards, marcelo

>
>> Regards, marcelo
>>>
>>> Cheers,
>>> Deguang
>>>
>>>
>>> Geoff Huston schrieb:
>>>
>>>> Hi,
>>>> This note starts the WG Last Call for comments on the three "base"  
>>>> Shim6 documents:
>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>> protocol"
>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>> Locator  Pair                                        Exploration 
>>>> Protocol for  IPv6
>>>>                                        Multihoming"
>>>> They can be found at:
>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>> detection-06.txt
>>>> Please review the documents carefully, and send your feedback to 
>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>> that  these documents
>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>> Standards.
>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>> October 2006 at 0800,  UTC+10
>>>>   Thanks,
>>>>         Geoff & Kurtis
>>>
>>>
>>>
>
>
>

Delivery-date: Mon, 09 Oct 2006 13:17:37 +0000
Date: Mon, 09 Oct 2006 16:16:23 +0300
From: Jari Arkko <[email-masked]>
To: Deguang Le <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}

If I understood this correctly, the request
was to provide a "diff" update as opposed
to "here's the new list" message that we
have now:
> You are right, I agree with you. However, there still may be the case
> where the shim6 host determines one of its locators is permanently
> unusable. I think in this case it is better to remove the unusable
> locator from the locator set. right? :-)
>
> By the way, I would like to discuss the efficiency of using the Locator
> List option for the addition/deletion of locator to/from the locator set
> further.
> Because this draft specifies that "ALL" the locators must be carried in
> the Locator List option (see page42), I think it is not efficient to use
> the Locator List option in the case where only one locator needs to be
> add or removed while other locators keep unchanged. I think it is not
> necessary to update those unchanged locators and repetitively perform
> locator verification for those unchanged locators each time when only a
> locator changes. As you said , it is expensive option. Right? :-)
>
> If my above issue is reasonable, do you think it is possible to define
> two new separate options (e.g. Locator Addtion option and Locator
> Deletion option) for adding a new locator to the locator set on a SHIM6
> context and for deleting a failured locator from the locator set on a
> SHIM6 context. 
>From a functional standpoint we could use either
the diff or the complete list approach. However, as
this was discussed during the protocol design,
people felt that the latter was a better choice.
It is true that the diff approach can be more
efficient in some cases. However, the benefits
are offset by higher complexity and the risk
of synchronization failures. Finally, I believe
that in most cases where the node is truly
mobile, the number of locators is likely
relatively small, so the real-world savings
may not be that big.

--Jari

Delivery-date: Mon, 09 Oct 2006 13:06:42 +0000
Date: Mon, 09 Oct 2006 16:05:18 +0300
From: Jari Arkko <[email-masked]>
To: =?ISO-8859-1?Q?Sébastien_Barré?= <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {3}

Sébastien,
> I have noticed a problem with the Hdr Ext Len field of REAP packets :
> The draft specifies this field like follows :
> -------------
> Next Header, Hdr Ext Len, 0, 0, Checksum
>
>      These are as specified in Section 5.3 of the SHIM6 protocol
>      description [I-D.ietf-shim6-proto].
> --------------
> So, looking at section 5.3 in the shim6 proto draft :
> --------------
> Hdr Ext Len:   8-bit unsigned integer.  Length of the shim6 header in
>                  8-octet units, not including the first 8 octets.
> --------------
> This means any shim6 or reap packet must have a length multiple of 8
> bytes. AFAIK, this is the case  for all shim6 messages defined in the
> proto draft. But that's not true for the failure detection draft in
> the case of the keepalive message : the keepalive message as defined
> is 12 bytes long, which cannot be encoded in the Hdr Ext Len field. I
> suggest extending it with a 4 bytes padding. In the current version of
> the draft I don't see other occurences of this problem.
>
> Nevertheless, when designing options in the future, we should take
> care of also enforcing a length multiple of 8 bytes.
Ah -- good catch. Thanks.

I have added a 32-bit reserved field at the end of the
keepalive message, before the options.

--Jari

Delivery-date: Mon, 09 Oct 2006 11:15:43 +0000
Date: Mon, 09 Oct 2006 13:14:53 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Victor Grishchenko <[email-masked]>
CC: [email-masked]
Subject: Re: Some questions on shim6

Victor,

Speaking for myself only:

Victor Grishchenko wrote:
> Good day!
> 
> I am a newbie here; I am not an expert in shim and, frankly, I am not  much
> involved with IPv6. Still, I am interested in this topic mostly on  
> academic
> grounds.
> 
> In particular, I have three questions.
> 
> 1) Do you agree that shim6 is an "ad-hoc" (introduced to add multihoming
> to IPv6)

I don't think it's ad hoc. There was a long analysis of many approaches
before shim6 was selected. It was carefully chosen to avoid damaging
existing functionality (in contrast to NAT, for example).

> 
> 2) Do you agree to the metaphor "shim6 is a kind of NAT inside the  
> stack" ?

It's too simple. Shim6 is stateful, signalled, symmetric, reversible,
and adaptive address translation. Classical NAT is stateless, unsignalled,
asymmetric, irreversible, non-adaptive address translation that damages
existing functionality.

> 3) An alternate path of vectorizing TCP/UDP probably was considered in
> the past. I mean, using multiple IPv6 addresses (a vector of) for a  single
> TCP connection; vectorizing all calculations performed by TCP. Do you  have
> any links to past proposals/discussions regarding this approach?

I think you need to study SCTP.

     Brian

Delivery-date: Mon, 09 Oct 2006 11:09:41 +0000
Date: Mon, 09 Oct 2006 13:08:00 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Deguang Le <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}

...
> So, the reasion why I ask these questions and make these comments is
> that I am not sure if SHIM6 can be used in the mobile environments where
> a host may change its attachment/location to Internet, namely change the
> locator (including locator additon and locator deletion).
> 
> In fact, the above two examples I described are exactly the situations
> that appear in the mobile environments. To my understanding, the
> specified locator update messages also can be used for mobility
> scenario. Now your answer confirms my understanding. Right?

However, shim6 is not supposed to be a mobility protocol -
so we would have to be very careful about asserting that it can
be used as a mobility protocol, since that was not one of the
design goals.

    Brian

Delivery-date: Mon, 09 Oct 2006 10:26:32 +0000
Date: Mon, 09 Oct 2006 12:24:02 +0200
From: =?ISO-8859-1?Q?Sébastien_Barré?= <[email-masked]>
To:  [email-masked]
Subject: comments on draft-ietf-shim6-failure-detection-06.txt {3}

Hi,

I have noticed a problem with the Hdr Ext Len field of REAP packets :
The draft specifies this field like follows :
-------------
 Next Header, Hdr Ext Len, 0, 0, Checksum

      These are as specified in Section 5.3 of the SHIM6 protocol
      description [I-D.ietf-shim6-proto].
--------------
So, looking at section 5.3 in the shim6 proto draft :
--------------
 Hdr Ext Len:   8-bit unsigned integer.  Length of the shim6 header in
                  8-octet units, not including the first 8 octets.
--------------
This means any shim6 or reap packet must have a length multiple of 8 
bytes. AFAIK, this is the case  for all shim6 messages defined in the 
proto draft. But that's not true for the failure detection draft in the 
case of the keepalive message : the keepalive message as defined is 12 
bytes long, which cannot be encoded in the Hdr Ext Len field. I suggest 
extending it with a 4 bytes padding. In the current version of the draft 
I don't see other occurences of this problem.

Nevertheless, when designing options in the future, we should take care 
of also enforcing a length multiple of 8 bytes.

regards,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCL, Belgium

Delivery-date: Sun, 08 Oct 2006 15:11:36 +0000
Date: Sun, 08 Oct 2006 17:09:23 +0200
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}

Hi Marcelo, all,
Thank you very much for your response.
Please see my comments inline...

marcelo bagnulo braun schrieb:

> Hi Deguang,
> 
> Thank you for the comments.
> 
> see my comments below...
> 
> El 05/10/2006, a las 12:07, Deguang Le escribió:
> 
>> Hi all,
>> A slight comments on draft-ietf-shim6-proto-05.txt
>>
>> -Page74
>> 10.1.  Sending Update Request messages
>>    When a host has a change in the locator set, then it can communicate
>>    this to the peer by sending an Update Request.
>>
>> To my understanding, the above stentence state the Update Request  
>> message (with  Locator List Option, right?)
> 
> 
> yes
> 
>>  is sent when (or if) the locator at the SHIM6 host is changed.
>> Right?
>>
> 
> yes
> 
>> But It is not clear for me about the "locator change", because the  
>> situation "locator change" is too general.
> 
> 
> i am not sure i am following.
> This is used whenever there is a change in the loccator set, in order  
> to inform the peer about the changes in the locator set.
> So while i agree that there are many reasons why the locator set can  
> change, i think that all of them are valid reasons to use the Update  
> message. I mean, do you see any situation where we could have a locator  
> change and the usage of the Update message wouldn't apply?

I don't mean that there are any situation where we could have a locator
change and the usage of the Update message wouldn't apply. ^-^
I mean: could the usage of the Update message apply in the mobility
situation where we could have a locator change? :-)

> 
>>  I think it would be better if this draft could provide some examples  
>> (cases) about the locator change in real applications. For examples, 
>> I  would like to know if the follwoing cases belong to the "locator  
>> change" situation described in this draft:
>> -A SHIM6 host is assigned a new usable locator at some interface of  
>> the SHIM6 host.
>>
> 
> We can add in the draft that a locator change is either to add new  
> locators to the locator set or to remove locators from it.
> 
>> -A SHIM6 host finds one of its locators is unusable or failure.
>>
> 
> Please note that when a host finds that one of its locators is  
> temporarily unusable e.g. it is unreachable, or there is a local  
> failure, it can use the Update message to inform about the situation or  
> it can simply convey Locator Preference infromation. This lasst option  
> is a cheaper option in terms of processing because of the security  checks

You are right, I agree with you. However, there still may be the case
where the shim6 host determines one of its locators is permanently
unusable. I think in this case it is better to remove the unusable
locator from the locator set. right? :-)

By the way, I would like to discuss the efficiency of using the Locator
List option for the addition/deletion of locator to/from the locator set
further.
Because this draft specifies that "ALL" the locators must be carried in
the Locator List option (see page42), I think it is not efficient to use
the Locator List option in the case where only one locator needs to be
add or removed while other locators keep unchanged. I think it is not
necessary to update those unchanged locators and repetitively perform
locator verification for those unchanged locators each time when only a
locator changes. As you said , it is expensive option. Right? :-)

If my above issue is reasonable, do you think it is possible to define
two new separate options (e.g. Locator Addtion option and Locator
Deletion option) for adding a new locator to the locator set on a SHIM6
context and for deleting a failured locator from the locator set on a
SHIM6 context.

> 
> 
>> If the above two examples belong to the "locator change" situation,  
>> then I would like to know if a SHIM6 host must (or can or need to)  
>> send the Locator Request message with Locator List option to its 
>> peers  when the SHIM6 host is assigned a new usable locator at some 
>> interface  of the SHIM6 host or when the SHIM6 host finds one of its 
>> locators is  unusable or failure.
> 
> 
> but this would be up to the host to decide based in its local policy  
> rather than a protocol issue imho
You are right, and I know what you mean. But, I'd only like to know,
from the functionality point of view, if the Update Request message with
Locator List option "CAN" be used for this purpose when the above two
situations occur. :-)
 From the your following explanations, I think you agree the Update
Request message with Locator List option "CAN" do this.

> 
> I mean if a host has a new locator it can either add it to all of its  
> established contexts, or to some of them or none of them depending of  
> local considerations. Moreover, a host does not need to add all its  
> locator to all its shim contexts. for instance a host could have a set  
> of locators tha it uses for certain communications (e.g. communications  
> within its own site) and some other set of locators that it uses for  
> other communications (e.g. intersite communications) All these cases  
> are perfectly ok and the spec supports any behaviour that the host  
> decides to choose
> A similar consideration applies to the case where the host looses on  
> locator. Depending on the situation it can either rmove from the  
> locator set using an Update message or it can mark it as broken using  
> the preference option or it can even do nothing and the peer will  
> determine that the locator pairs contianing this locator are  
> unreachable and will not use them. All these approaches are possibel  
> and they are supported in the spec.
> 
> So, i am not sure we need to add additional constraints on how ths  
> needs to be used, what do you think?

Thank you again, I think your answer confirms my understanding.

This draft specifies the messages, which are used for multihoming, but
it does not clearly present (or explain) if these specifications could
be appled for mobilty usage.

So, the reasion why I ask these questions and make these comments is
that I am not sure if SHIM6 can be used in the mobile environments where
a host may change its attachment/location to Internet, namely change the
locator (including locator additon and locator deletion).

In fact, the above two examples I described are exactly the situations
that appear in the mobile environments. To my understanding, the
specified locator update messages also can be used for mobility
scenario. Now your answer confirms my understanding. Right?

> 
> Regards, marcelo
> 
> 
>>
>> Cheers,
>> Deguang
>>
>>
>> Geoff Huston schrieb:
>>
>>> Hi,
>>> This note starts the WG Last Call for comments on the three "base"  
>>> Shim6 documents:
>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>> protocol"
>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator  
>>> Pair                                        Exploration Protocol for  
>>> IPv6
>>>                                        Multihoming"
>>> They can be found at:
>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>> detection-06.txt
>>> Please review the documents carefully, and send your feedback to the  
>>> SHIM6 list.  Please also indicate whether or not you believe that  
>>> these documents
>>> are ready to go to the IESG for publication as a set of Proposed  
>>> Standards.
>>> This Working Group Last Call will end in two weeks, on the 12th  
>>> October 2006 at 0800,  UTC+10
>>>   Thanks,
>>>         Geoff & Kurtis
>>
>>
>>
> 

Delivery-date: Sun, 08 Oct 2006 15:11:05 +0000
Date: Sun, 08 Oct 2006 17:09:33 +0200
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {2}

Hi marcelo, all,
Please see comments inline...

marcelo bagnulo braun schrieb:

> Hi again,
> 
> below...
> 
> El 06/10/2006, a las 10:43, Deguang Le escribió:
> 
>> Hi all,
>> A slight comments on draft-ietf-shim6-proto-05.txt
>>
>> -Page45
>>    When the Element length equals one, then the element consists of  only
>>    a one octet flags field.  The currently defined set of flags are:
>>
>>       BROKEN: 0x01
>>
>>       TEMPORARY: 0x02
>>
>>    The intent of TEMPORARY is to allow the distinction between more
>>    stable addresses and less stable addresses when shim6 is combined
>>    with IP mobility, when we might have more stable home locators, and
>>    less stable care-of-locators.
>>
>> In above statement and context in this draft, no detailed explanation  
>> for "BROKEN" and its usage.
>> I think it is better if there is some accurate explanations for 
>> BROKEN  and how it is used in this Locator Preference option.
>>
> 
> agree
> 
> basically the usage of the BROKEN flag is intended for when the host  
> knows thanks to local information that a locator is temporarily  
> unavailbale/unreachable, so it can mark it as such, so that the peer  
> doesn't use it for communicating.

I agree with you, it is a good way to deal with the temporary failure of
locator using the BROKEN flag.
However, if the locator is permanently unavailbale/unreachable say due
to mobility or rehoming, I think it is not necessary to keep the
unavailable locator in the locator set. Right?

> 
> As mentioned in the other email, another option would be to remove from  
> the locator set using a Update message, but i guess this option is  
> cheaper in terms of processing (cheaper security checks)

As for security check, I am not familiar with security issue, so I don't
know why the Locator Preference option need not verification check. ^-^

Does anyone provide some explanations about it? Thank in advance.

> 
> 
>> Besides, the above explanation for "TEMPORARY" is still not clear for  
>> me. What are the more stable addresses and what are the less stable  
>> addresses?
> 
> 
> the goal here is that if the host knows that there are some addresses  
> that may change rapidly, it can mark them as such, so that the peer use  
> more aggresive failure detection mechanisms on that address.

I think it is an interesting usage although it is not easy to determine
which addresses belong to more stable or less stable. :-)

> 
> In the case of MIP a HoA is a more stable address and a CoA is a less  
> stable address
> 
In my own veiw, I don't think the HoA is the more stable address and the
CoA is the less stable address because the mobile node may stay at any
place including the home network or foreign network at any time.
For example, a mobile node may access to the Internet through some
foreign network, then it may moves between the foreign networks, which
are far from the home network. In this case, the HoA may never be usable
during the whole communication period. Therefore, we could not regard 
the HoA as the more stable address. Right?

> 
> 
>>  I think it is better if this draft could provides some special  
>> situations about them. Morever, I also can not understand how the  
>> TEMPORARY can be used to distinguish them.
>>
> 
> The usage would be that it will include the Temporary flag when  
> conveying CoA information in the locator set.

As my above statements, I think it is not suitable to tag the CoA as
Temporary. Right? :-)

> 
> Do you think that additional text is required to explain this?
Yes, I think these flags are very important in order to put the Locator
Preference option in real use, we need to formulate these flags'
functions and their usage (e.g. applied situations) more clearly.

With best regards,
Deguang

> 
> Regards, marcelo
> 
> 
>> Cheers,
>> Deguang
>>
>>> Geoff Huston schrieb:
>>>
>>>> Hi,
>>>>
>>>> This note starts the WG Last Call for comments on the three "base"  
>>>> Shim6 documents:
>>>>
>>>>
>>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>>> protocol"
>>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>>
>>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and 
>>>> Locator  Pair                                        Exploration 
>>>> Protocol for  IPv6
>>>>                                        Multihoming"
>>>>
>>>> They can be found at:
>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>>     http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>>> detection-06.txt
>>>>
>>>> Please review the documents carefully, and send your feedback to 
>>>> the  SHIM6 list.  Please also indicate whether or not you believe 
>>>> that  these documents
>>>> are ready to go to the IESG for publication as a set of Proposed  
>>>> Standards.
>>>>
>>>> This Working Group Last Call will end in two weeks, on the 12th  
>>>> October 2006 at 0800,  UTC+10
>>>>
>>>>
>>>>   Thanks,
>>>>
>>>>
>>>>         Geoff & Kurtis
>>
>>
>>
> 

Delivery-date: Sun, 08 Oct 2006 09:22:07 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {2}
Date: Sun, 8 Oct 2006 11:21:52 +0200
To: Deguang Le <[email-masked]>

Hi again,

below...

El 06/10/2006, a las 10:43, Deguang Le escribió:

> Hi all,
> A slight comments on draft-ietf-shim6-proto-05.txt
>
> -Page45
>    When the Element length equals one, then the element consists of  
> only
>    a one octet flags field.  The currently defined set of flags are:
>
>       BROKEN: 0x01
>
>       TEMPORARY: 0x02
>
>    The intent of TEMPORARY is to allow the distinction between more
>    stable addresses and less stable addresses when shim6 is combined
>    with IP mobility, when we might have more stable home locators, and
>    less stable care-of-locators.
>
> In above statement and context in this draft, no detailed explanation  
> for "BROKEN" and its usage.
> I think it is better if there is some accurate explanations for BROKEN  
> and how it is used in this Locator Preference option.
>

agree

basically the usage of the BROKEN flag is intended for when the host  
knows thanks to local information that a locator is temporarily  
unavailbale/unreachable, so it can mark it as such, so that the peer  
doesn't use it for communicating.

As mentioned in the other email, another option would be to remove from  
the locator set using a Update message, but i guess this option is  
cheaper in terms of processing (cheaper security checks)

> Besides, the above explanation for "TEMPORARY" is still not clear for  
> me. What are the more stable addresses and what are the less stable  
> addresses?

the goal here is that if the host knows that there are some addresses  
that may change rapidly, it can mark them as such, so that the peer use  
more aggresive failure detection mechanisms on that address.

In the case of MIP a HoA is a more stable address and a CoA is a less  
stable address

>  I think it is better if this draft could provides some special  
> situations about them. Morever, I also can not understand how the  
> TEMPORARY can be used to distinguish them.
>

The usage would be that it will include the Temporary flag when  
conveying CoA information in the locator set.

Do you think that additional text is required to explain this?

Regards, marcelo

> Cheers,
> Deguang
>
>> Geoff Huston schrieb:
>>> Hi,
>>>
>>> This note starts the WG Last Call for comments on the three "base"  
>>> Shim6 documents:
>>>
>>>
>>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>>> protocol"
>>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>>
>>> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator  
>>> Pair                                        Exploration Protocol for  
>>> IPv6
>>>                                        Multihoming"
>>>
>>> They can be found at:
>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>>     
>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>>> detection-06.txt
>>>
>>> Please review the documents carefully, and send your feedback to the  
>>> SHIM6 list.  Please also indicate whether or not you believe that  
>>> these documents
>>> are ready to go to the IESG for publication as a set of Proposed  
>>> Standards.
>>>
>>> This Working Group Last Call will end in two weeks, on the 12th  
>>> October 2006 at 0800,  UTC+10
>>>
>>>
>>>   Thanks,
>>>
>>>
>>>         Geoff & Kurtis
>
>

Delivery-date: Sun, 08 Oct 2006 09:18:15 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {1}
Date: Sun, 8 Oct 2006 11:14:18 +0200
To: Deguang Le <[email-masked]>

Hi Deguang,

Thank you for the comments.

see my comments below...

El 05/10/2006, a las 12:07, Deguang Le escribió:

> Hi all,
> A slight comments on draft-ietf-shim6-proto-05.txt
>
> -Page74
> 10.1.  Sending Update Request messages
>    When a host has a change in the locator set, then it can communicate
>    this to the peer by sending an Update Request.
>
> To my understanding, the above stentence state the Update Request  
> message (with  Locator List Option, right?)

yes

>  is sent when (or if) the locator at the SHIM6 host is changed.
> Right?
>

yes

> But It is not clear for me about the "locator change", because the  
> situation "locator change" is too general.

i am not sure i am following.
This is used whenever there is a change in the loccator set, in order  
to inform the peer about the changes in the locator set.
So while i agree that there are many reasons why the locator set can  
change, i think that all of them are valid reasons to use the Update  
message. I mean, do you see any situation where we could have a locator  
change and the usage of the Update message wouldn't apply?

>  I think it would be better if this draft could provide some examples  
> (cases) about the locator change in real applications. For examples, I  
> would like to know if the follwoing cases belong to the "locator  
> change" situation described in this draft:
> -A SHIM6 host is assigned a new usable locator at some interface of  
> the SHIM6 host.
>

We can add in the draft that a locator change is either to add new  
locators to the locator set or to remove locators from it.

> -A SHIM6 host finds one of its locators is unusable or failure.
>

Please note that when a host finds that one of its locators is  
temporarily unusable e.g. it is unreachable, or there is a local  
failure, it can use the Update message to inform about the situation or  
it can simply convey Locator Preference infromation. This lasst option  
is a cheaper option in terms of processing because of the security  
checks

> If the above two examples belong to the "locator change" situation,  
> then I would like to know if a SHIM6 host must (or can or need to)  
> send the Locator Request message with Locator List option to its peers  
> when the SHIM6 host is assigned a new usable locator at some interface  
> of the SHIM6 host or when the SHIM6 host finds one of its locators is  
> unusable or failure.

but this would be up to the host to decide based in its local policy  
rather than a protocol issue imho

I mean if a host has a new locator it can either add it to all of its  
established contexts, or to some of them or none of them depending of  
local considerations. Moreover, a host does not need to add all its  
locator to all its shim contexts. for instance a host could have a set  
of locators tha it uses for certain communications (e.g. communications  
within its own site) and some other set of locators that it uses for  
other communications (e.g. intersite communications) All these cases  
are perfectly ok and the spec supports any behaviour that the host  
decides to choose
A similar consideration applies to the case where the host looses on  
locator. Depending on the situation it can either rmove from the  
locator set using an Update message or it can mark it as broken using  
the preference option or it can even do nothing and the peer will  
determine that the locator pairs contianing this locator are  
unreachable and will not use them. All these approaches are possibel  
and they are supported in the spec.

So, i am not sure we need to add additional constraints on how ths  
needs to be used, what do you think?

Regards, marcelo

>
> Cheers,
> Deguang
>
>
> Geoff Huston schrieb:
>
>> Hi,
>> This note starts the WG Last Call for comments on the three "base"  
>> Shim6 documents:
>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim  
>> protocol"
>>  draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator  
>> Pair                                        Exploration Protocol for  
>> IPv6
>>                                        Multihoming"
>> They can be found at:
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>     
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
>> detection-06.txt
>> Please review the documents carefully, and send your feedback to the  
>> SHIM6 list.  Please also indicate whether or not you believe that  
>> these documents
>> are ready to go to the IESG for publication as a set of Proposed  
>> Standards.
>> This Working Group Last Call will end in two weeks, on the 12th  
>> October 2006 at 0800,  UTC+10
>>   Thanks,
>>         Geoff & Kurtis
>
>

Delivery-date: Fri, 06 Oct 2006 14:50:21 +0000
Date: Fri, 06 Oct 2006 10:43:19 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: comments on draft-ietf-shim6-proto-05.txt {2}

Hi all,
A slight comments on draft-ietf-shim6-proto-05.txt

-Page45
    When the Element length equals one, then the element consists of only
    a one octet flags field.  The currently defined set of flags are:

       BROKEN: 0x01

       TEMPORARY: 0x02

    The intent of TEMPORARY is to allow the distinction between more
    stable addresses and less stable addresses when shim6 is combined
    with IP mobility, when we might have more stable home locators, and
    less stable care-of-locators.

In above statement and context in this draft, no detailed explanation 
for "BROKEN" and its usage.
I think it is better if there is some accurate explanations for BROKEN 
and how it is used in this Locator Preference option.
Besides, the above explanation for "TEMPORARY" is still not clear for 
me. What are the more stable addresses and what are the less stable 
addresses? I think it is better if this draft could provides some 
special situations about them. Morever, I also can not understand how 
the TEMPORARY can be used to distinguish them.

Cheers,
Deguang

> Geoff Huston schrieb:
> 
>> Hi,
>>
>> This note starts the WG Last Call for comments on the three "base" 
>> Shim6 documents:
>>
>>
>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
>>  
>> draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>
>> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator 
>> Pair                                        Exploration Protocol for IPv6
>>                                        Multihoming"
>>
>> They can be found at:
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>    
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt 
>>
>>
>> Please review the documents carefully, and send your feedback to the 
>> SHIM6 list.  Please also indicate whether or not you believe that 
>> these documents
>> are ready to go to the IESG for publication as a set of Proposed 
>> Standards.
>>
>> This Working Group Last Call will end in two weeks, on the 12th 
>> October 2006 at 0800,  UTC+10
>>
>>
>>   Thanks,
>>
>>
>>         Geoff & Kurtis

Delivery-date: Thu, 05 Oct 2006 10:08:41 +0000
Date: Thu, 05 Oct 2006 12:07:36 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: comments on draft-ietf-shim6-proto-05.txt {1}

Hi all,
A slight comments on draft-ietf-shim6-proto-05.txt

-Page74
10.1.  Sending Update Request messages
    When a host has a change in the locator set, then it can communicate
    this to the peer by sending an Update Request.

To my understanding, the above stentence state the Update Request 
message (with  Locator List Option, right?) is sent when (or if) the 
locator at the SHIM6 host is changed.
Right?

But It is not clear for me about the "locator change", because the 
situation "locator change" is too general. I think it would be better if 
this draft could provide some examples (cases) about the locator change 
in real applications. For examples, I would like to know if the 
follwoing cases belong to the "locator change" situation described in 
this draft:
-A SHIM6 host is assigned a new usable locator at some interface of the 
SHIM6 host.
-A SHIM6 host finds one of its locators is unusable or failure.

If the above two examples belong to the "locator change" situation, then 
I would like to know if a SHIM6 host must (or can or need to) send the 
Locator Request message with Locator List option to its peers when the 
SHIM6 host is assigned a new usable locator at some interface of the 
SHIM6 host or when the SHIM6 host finds one of its locators is unusable 
or failure.

Cheers,
Deguang

Geoff Huston schrieb:

> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" 
> Shim6 documents:
> 
> 
> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
>  
> draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator Pair 
>                                        Exploration Protocol for IPv6
>                                        Multihoming"
> 
> They can be found at:
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
> 
> Please review the documents carefully, and send your feedback to the SHIM6 
> list.  Please also indicate whether or not you believe that these documents
> are ready to go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 12th October 
> 2006 at 0800,  UTC+10
> 
> 
>   Thanks,
> 
> 
>         Geoff & Kurtis

Delivery-date: Tue, 03 Oct 2006 13:26:38 +0000
Date: Tue, 03 Oct 2006 16:24:00 +0300
From: Jari Arkko <[email-masked]>
To: Deguang Le <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {2}

> -Page9
>    It is also necessary to
>    track remote address information from the peer.  For instance, if the
>    peer's currently used address is no longer in use, mechanism to relay
>    that information is needed.  The Update message in the SHIM6 protocol
>    is used for this purpose [I-D.ietf-shim6-proto].
> What is "Update message"?
> I can not find "Update message" in [I-D.ietf-shim6-proto] except an
> Update Request message and an Update Acknowledgement message.
> Therfore, I would like to know if they are the same thing.
>
> If they are the same thing, to my understanding, I thinks the Update
> Request message and the Update Acknowledgement message only are used
> to inform a remote peer of local information, not to trace the remote
> peer status at all.
Thanks for noting this. The text should say "Update Request message"
instead. I have now taken this into account in the source XML.

As for the usage of the Update Request message, it is indeed
reporting local information. But once that local information
reaches the receiver, it becomes the receiver's task to take
it into account. For instance, if the sender indicated that
it is no longer able to use address X, the receiver should
refrain from using X from now on.

--Jari

Delivery-date: Sun, 01 Oct 2006 10:39:36 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {2}
Date: Sun, 1 Oct 2006 11:30:54 +0200
To: Deguang Le <[email-masked]>

On 30-sep-2006, at 16:47, Deguang Le wrote:

> This paragraph presents "SHIM6 needs to avoid sending packets
> concurrently over multiple path".

> However, in RFC 3582 - Goals for IPv6 Site-Multihoming Architectures,
> Load sharing is one of the goals of multihoming.
> 3.1.2.  Load Sharing
>    By multihoming, a site should be able to distribute both inbound  
> and
>    outbound traffic between multiple transit providers.  This goal is
>    for concurrent use of the multiple transit providers, not just the
>    usage of one provider over one interval of time and another  
> provider
>    over a different interval.

> Therfore, I would like to know if this sentence "SHIM6 needs to avoid
> sending packets concurrently over multiple path" means that SHIM6
> doesn't support load sharing?

The text you cite pertains to individual shim contexts. Often, a shim  
context will be used for a single TCP session, and it's considered  
suboptimal to have packets belonging to the same TCP session travel  
through different paths, because this introduces packet reordering  
which impedes TCP performance.

However, shim6 still supports load balancing by allowing different  
contexts to use different addresses, so that part of the contexts  
will generate traffic over one path and part of the contexts over  
another path.

Note though, that most traffic will be associated with contexts for  
which no shim6 address rewriting is active, so load balancing greatly  
depends on things outside the scope of shim6, such as information in  
the DNS and routing.

> -Page9
>    It is also necessary to
>    track remote address information from the peer.  For instance,  
> if the
>    peer's currently used address is no longer in use, mechanism to  
> relay
>    that information is needed.  The Update message in the SHIM6  
> protocol
>    is used for this purpose [I-D.ietf-shim6-proto].

> What is "Update message"?

I still have a review of the shim6 proto draft on my to do list, so  
I'll keep my eye out for this. Maybe Erik or Marcelo can answer this?

Thanks for the comments,

Iljitsch

Delivery-date: Sun, 01 Oct 2006 07:29:34 +0000
Date: Sun, 01 Oct 2006 10:28:12 +0300
From: Jari Arkko <[email-masked]>
To: Deguang Le <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt

Hi,

Thanks for your comments. Some further
discussion inline:
> -Page6
>       Note 2: In theory, it would also be possible for hosts to learn
>       about routing failures for a particular selected source prefix, if
>       only suitable protocols for this purpose existed.  Some proposals
>       in this space have been made, see, for instance
>       [I-D.bagnulo-shim6-addr-selection] and
>       [I-D.huitema-multi6-addr-selection], but none have been
>       standardized to date.
>
> This paragraph shows [I-D.bagnulo-shim6-addr-selection] and
> [I-D.huitema-multi6-addr-selection] are two unstandardized proposals
> for local routing  failure detection.
Right.
> Then, I think the neighbour unreachability detection in [RFC2461] MAY
> be a standardized proposal for this purpose.
The section talks earlier about using NUD to your
default router to determine if the address is locally
OK. What this does not help with is failures further
away. As you point out, there are no standardized
proposals for hosts being aware of such failures.

So, yes, NUD is indeed usable in this context, for
a limited part of the problem. But this is what we
already have in the draft.

--Jari