Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
From: Iljitsch van Beijnum <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Fri, 30 Jun 2006 12:58:04 +0200

On 29-jun-2006, at 12:50, Jari Arkko wrote:

>> One way to address this is to split the reachability detection into a
>> shim-specific part (the keepalives) and a generic part (the path
>> exploration), so that the generic part can evolve independent of  
>> shim6.

> It would be great if we could do something like this,
> but it seems that the employment of multiple different
> protocols (in the protocol number/port number sense)
> could lead to a situation where exploration says we have
> connectivity but Shim6 says we don't. I'd like to avoid that.

See my message "reachability also for non-shim protocols". My  
conclusion is that there aren't sufficient benefits in sharing a  
reachability detection protocol, sharing reachability hints between  
protocols would be better.

>> I think it's a good idea to consider TCP ACKs with no user data as
>> non-data packets that don't need to generate return traffic as well.

> Hmm... in order for that to be useful (as an optimization), it would
> have to be
> supported by both sides. That would set a requirement that the shim  
> layer
> can peek inside the TCP packets. Not sure if we want to do that.

Yes, it would have to be on both sides. But it's simple enough: next  
header = 17, remaining length for the packet = data offset. Is that  
really problematic?

>>> Keepalives are only used if there's one-way communication. Since the
>>> other side sends a keepalive, its not sending anything else at that
>>> time. Hence we have no need for keepalives.

>> But do we need this rule? It may make implementations more complex
>> without any benefit.

> Assuming we want to avoid keepalives for periods of bidirectional
> communication or silence, I think we do need it. If you send a  
> keepalive
> based on a keepalive, you don't have a termination condition.

No, we NEVER send a keepalive for a keepalive (or any other packet  
that doesn't have any upper layer protocol following the shim header).

>> Why not leave it up to the implementers? If we say that after 10
>> seconds the full path exploration starts, implementers are free to
>> experiment with what works well (3, 4, 8 seconds between keepalives)
>> without any need to revisit the spec.

> I have now made it clear that these are recommended defaults,
> but that more experimentation is needed to determine the best
> values. And that implementations can choose what they want to
> do.

Ok.

>> I severely dislike having fixed length data in TLV format, because
>> that makes parsing much harder. If you look at Van Jacobson's work
>> with TCP you'll see that a fixed header allows extremely streamlined
>> implementations.
>
> If we move the current option contents to the messages (as discussed
> earlier),
> this will simplify things a bit. I think we need to retain TLVs for  
> the
> rest, because
> that allows multiple appearances of the same value (e.g. reception
> report) and
> future extensibility.

The same thing multiple times doesn't necessarily need TLVs, but yes,  
we should keep TLV for real options, i.e., ones that are  
optional  :-)  and may be defined in the future.

> Re: timer values etc. I don't currently have a good idea of what the
> behaviour based on these fields would be. Maybe you do.

If you send packets over different paths and start sending packets at  
fairly short intervals in the beginning, it's entirely possible that  
packet 2 from A arrives at B earlier than packet 1. It's also  
possible that a particular round trip has a fast leg and a slow leg.  
If we know how long the remote host has had the packets we sent  
before sending a reply, we gain relative delay information for each  
of them, allowing us to arrive at very good delay information which  
can then be used to select the best address pair in each direction.

I.e., when you go to Montreal and come back, say, 8 days later, I  
don't know whether your RTT is 2 hours and you stayed there for 190  
hours, or if your RTT was 3 days and you stayed 2 days or something  
in between. If I know how long you were on the ground I can calculate  
your RTT and if several people take the trip I can draw some  
conclusions about who had travel delays, and even infer some  
information on whether it was on the way out or on the way back.

> The spec says it should return multiple identities, everything that it
> has recently seen
> (up to some reasonable limit).

Excellent.

Iljitsch

Delivery-date: Fri, 30 Jun 2006 10:38:05 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: draft-ietf-shim6-locator-pair-selection-00.txt
Date: Fri, 30 Jun 2006 12:37:21 +0200
To: marcelo bagnulo braun <[email-masked]>

On 29-jun-2006, at 13:12, marcelo bagnulo braun wrote:

>> I'm not sure though that your locator pair selection draft should  
>> be a separate document... Maybe it's better to integrate it with  
>> the failure/reachability detection document.

> i am not sure about this, especially if we want to leave the door  
> open to allow the faildet protocol to be used for other  
> protocols... the locator pair selection seems quite shim6 specific  
> to me...

We can always decide on this later.

>>>    We define the local set of locally-operational locators (LOLs 
>>> (local))
>>>    as the local locators that are included in the local locator set
>>>    (Ls(local) as defined in [1]) and that are locally operational as
>>>    defined in [2].  Locally operational addresses are discovered  
>>> through
>>>    local means that are outside of the scope of this document.

>>> so the definition states that these are not all the operational  
>>> addresses (not for the peer nor for the local host) but the  
>>> operational addresses that are included in the particular context

>> Sure, but it's still not the best possible name.

> suggestions...?

How about local locator set and remote locator set?

>> You also include the whole story on how to do this, which is the  
>> same (at least as far as I remember) as in RFC 2782. I think a  
>> reference is sufficient, especially since there is no pressing  
>> need that the actual calculation happens in this particular way.

> well, the goal here is to simplify the reading and not forcing the  
> reader to look for that in the other doc...

But it's not like the whole thing can't be understood without details  
on how to handle weights. I think most people understand the idea  
when you say that the chance of selecting an address must be equal to  
its weight relative to the sum of the weights of the addresses under  
consideration. Maybe someone who is a bit more mathematically  
inclined can express this in a formula... (ASCII formula??)

>> Actually, for this purpose there is no real reason for the numbers  
>> to be truly random, as long as their distribution is fairly even  
>> and different instances of an implementation don't all start with  
>> the same value.

> yes pseudo random number would be acceptable i guess

> i can change this

It's probably enough to state that strong random numbers aren't  
required. I think there is a reference to a randomness document,  
maybe there is something in there that applies to this, and if not,  
it would be possible to say that that document doesn't apply to these  
specific random numbers.

>> Agree. However, don't forget that the way something is explained  
>> in a draft will be the default way it is implemented unless there  
>> are important reasons to do it otherwise.

> yes, but my idea was to, once we agree on the rules, include in the  
> draft some implementations guidelines, describing this type of  
> formulas that you suggest that summarize a set of rules...

Ok.

>>>> 3: isn't this covered by the notion of being locally operational?

>>> i don't think so, because one thing is that a given address is  
>>> locally non operational and another thing is that a address pair  
>>> is non operational. I mean, two locally operational addresses may  
>>> perfectly result in a non operational address pair (because the  
>>> path is broken)

>> Yes, but can we know this before the pair is tested with a probe?  
>> That seems unlikely.

> agree
> but then you create all the potentially reachable locator pairs  
> using the locally operational addresses and then you try them to  
> figure out which of those are actually reachable.

> So you discard the non locally operational addresses from the start  
> and then you probe with the the others to see which ones are  
> actually working

Yes. You would probably even want to remove known non-operational  
addresses from the set of addresses communicated to the peer and thus  
they wouldn't be eligible for use as locators anyway. (Except in the  
case of the ULID.)

>> What I'm afraid of is that a context may rehome several times in  
>> quick succession because of this rule... That would be suboptimal.

> indeed, but i fail to see how this would happen...
> i mean you will only try to change after a failure has been  
> detected, right? so if no failure is detected, no rehoming,  
> independetly of what the rules for the preferred locator pair to  
> use next states...

It also depends on the probing. If you rehome to address A and then  
start probing address B then obviously, if B also works, the age for  
B's reachability is less than that of A's reachability. So you have  
the potential to rehome after every probe. That shouldn't be a  
problem if you only probe addresses you know you want to rehome to if  
they're reachable, but it could be troublesome if the probe  
scheduling isn't very strict so unnecessary probes may happen.

>> There is a lot to be said for limiting shim operations to global  
>> unicast addresses only, but I'm afraid that's too simple: it could  
>> be very useful to be able to use the shim on unique site locals in  
>> the cases where two sites have a private interconnect so they can  
>> reach each other using this type of addresses.

> agree

One thing that we may want to consider: prefer locators that are of  
the same scope as the ULIDs. So global locators are preferred when  
the ULID is global, ULA locators for a ULA ULID (ULAID?).

>> However, I don't see how using any kind of ambiguous addresses,  
>> such as link locals or old school site locals can work reliably.

> may agree with this too

> i don't have a problem eliminating site and link local addresses  
> form here

Anyone else have an opinion?

>>> i thing avoiding deprecated addresses may be useful...

>> I don't. Either deprecated addresses work, so we use them, or they  
>> don't work, so we don't use them. No special case handling required.

> but if they are deprecated, they may stop working anytime soon,  
> right? (for some definition of anytime)

I suppose if you have two addresses that are otherwise 100% equal,  
selecting the non-deprecated one would make sense. But that would be  
at the very bottom of my list of selection criteria.

>> Ok, this is the BGP style of rule processing. Upon rereading the  
>> list of rules I see that this should work. However, some of the  
>> "prefer" or "avoid" rules should really be "only accept" or "never  
>> use" rules, such as don't mix address families and don't mix scopes.

> with families i agree

> with scopes, mixed scopes may work

Ok.

>>> this is also included in rfc3484 i think and in the case of a  
>>> locator selection for the shim, it makes more sense to use a temp  
>>> address as oposed to the rfc3484 case, where you usually want to  
>>> prefer a public address.

>> First of all, I don't think it's a good idea to copy a rule just  
>> because it's in a different place as well. This only makes it  
>> harder to get rid of it when it turns out it was not a good rule.

> well, actually in this case, the rule is exactly the oposite...

Strange...

>> Second, _using_ temporary or non-temporary addresses isn't all  
>> that interesting in our case, it's _disclosing_ those addresses to  
>> the other side that's important. So to be true to the intent of  
>> RFC 3041 we should make sure we only include temporary addresses  
>> in the locator set that we send to the other side during shim  
>> negotiations.

> yes, you are right... we have talked about including some comment  
> about this in the shim protocol document...

> so would you say that once that the temp addresses have been  
> included in the locator set, we don't need to make a distinction  
> when selecting the address? i.e. remove this rule and only leave  
> the cosniderations about including temp addresses in the locator sets?

I think it makes sense to move some considerations, such as whether  
an address is known to be non-operational, of an inappropriate  
(ambiguous) scope, temporary/non-temporary to a different place where  
addresses are selected for inclusion in the set of addresses  
communicated to the other side. This can be in this draft, or in the  
main shim protocol draft. Then, inappropriate pairings are removed  
and then the preference is evaluated. In preference evaluation I  
don't think we need temp/non-temp. But I guess implementers can add  
this if they think it's important.

It may be a good idea to create an explicit place where  
implementation specific choices can be made. So we have "strong"  
rules from your list, then all the stuff implementers want to add is  
looked at, and finally, "weak" rules from your list.

>>>> 17: may want to make this one of the first rules after making  
>>>> sure there is reachability.  :-)

>>> this is when you need to select a locator pair after a failure, i  
>>> guess so this rule would result in returning to the ulid pair  
>>> once that the alternative locator pair that is being used  
>>> fails... but we can remove this one...

>> No, it's a good rule, it's just that I would go back to the ULIDs  
>> unless there is a very big reason to avoid them, not have this  
>> rule sit at the very end as kind of a tie breaker.

> ok, where would you put it?

I would like to have it before rule 5, but this may be hard to  
implement without annoying corner cases, so maybe after 5?

Iljitsch

Delivery-date: Thu, 29 Jun 2006 11:21:12 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: reachability also for non-shim protocols
Date: Thu, 29 Jun 2006 14:21:07 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 29/06/2006, a las 13:53, Iljitsch van Beijnum escribi=F3:

>
> So a good use of hints makes having a shared probing protocol mostly=20=

> unnecessary.
>
>

i guess that an option would be to revisit Dave Crocker's celp idea...

http://www.watersprings.org/pub/id/draft-crocker-celp-00.txt

Regards, marcelo

Delivery-date: Thu, 29 Jun 2006 11:12:52 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-locator-pair-selection-00.txt
Date: Thu, 29 Jun 2006 14:12:40 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 29/06/2006, a las 13:29, Iljitsch van Beijnum escribi=F3:

> On 28-jun-2006, at 13:15, marcelo bagnulo braun wrote:
>
>>> Note that this draft overlaps to a large degree with =20
>>> http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect=20
>>> -00.txt (STILL not posted by the secretariat 8 days after the =20
>>> fact...)
>
>> ok, i will comment on this draft in a separate email, but we should =20=

>> probably try to produce a single document then...
>
> I'm not sure though that your locator pair selection draft should be a =
=20
> separate document... Maybe it's better to integrate it with the =20
> failure/reachability detection document.
>

i am not sure about this, especially if we want to leave the door open =20=

to allow the faildet protocol to be used for other protocols... the =20
locator pair selection seems quite shim6 specific to me...

>>> Also, just before section 2.2 the text ends and without =20
>>> introduction, there is a formula. It is not immediately obvious that =
=20
>>> this formula means the same thing as the preceding paragraph.
>
>> strange... actually the attempt was that the formula is the exact =20
>> formalization of the previous paragraph... do you think there is a =20=

>> mistake?
>
> No, that's not what I wanted to say. What I mean is: it's not obvious =20=

> that the formula IS the same thing as what's said in the paragraph. So =
=20
> you may want to say explicitly that the formula expresses the same =20
> thing as the text so people won't be confused.
>

ok

>> or just that a sentence like "this means that the candidate locator =20=

>> pair set can be constructed as follows" would be enough?
>
> If you say it in that way people may still think the formula means =20
> something different than the text. The point is that if you understand =
=20
> the text you don't have to spend time trying to figure out what the =20=

> formula means as long as you know it means the same thing as the text.
>

ok will try to express this

>>> I don't think using LOLs(peer) is a good choice, because this =20
>>> assumes that we always know what the LOLs for the peer are, without =20=

>>> regard to the process of communicating the set back and forth or the =
=20
>>> possibility that a peer may not disclose all of its LOLs. Another =20=

>>> name for this would be better.
>
>> but the draft defines:
>
>>    We define the local set of locally-operational locators =20
>> (LOLs(local))
>>    as the local locators that are included in the local locator set
>>    (Ls(local) as defined in [1]) and that are locally operational as
>>    defined in [2].  Locally operational addresses are discovered =20
>> through
>>    local means that are outside of the scope of this document.
>
>> so the definition states that these are not all the operational =20
>> addresses (not for the peer nor for the local host) but the =20
>> operational addresses that are included in the particular context
>
> Sure, but it's still not the best possible name.
>

suggestions...?

>>> I'm not sure if reachable/unknown/unreachable is expressive enough, =20=

>>> maybe it's better to express this as a more gliding scale. I'm not =20=

>>> sure yet, though.
>
>> well, there is also the age of the reachability information =20
>> considered, making a scale among locator pairs for which a =20
>> reachability information is available... what else would you include =20=

>> in this scale?
>
> I would also take the preference values and maybe scope and create one =
=20
> value that can be used to rank locator pairs.
>

right this is what we are talking about below...

> It seems obvious to say something is reachable or unreachable, but the =
=20
> problem is that you never really know for sure, because thins can have =
=20
> changed since the last probe. So it's important to add a confidence =20=

> level, which would be the age of the reachable/unreachable =20
> information. But that's two values, you can wrap that into one by =20
> making reachable 100% and unreachable -100% and over time regress to =20=

> 0% if no newer information becomes available.
>

but this is the age as it is used in the current draft i think... i =20
mean, locator paris with newer reachability information are prefered =20
over those with older information...

>>> I see you copied the weight calculation from the SRV RFC. Wouldn't =20=

>>> it be easier just to say what the results should be and refer to =20
>>> this RFC for an example?
>
>> well, actually the draft states:
>
>>   The weight field express the relative weight for locators with the
>>    same priority, and as defined in [8] larger weights should be =20
>> given a
>>    proportionally higher probability of being selected.
>
>> being
>
>>    [8]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
>>         specifying the location of services (DNS SRV)", RFC 2782,
>>         February 2000.
>
>> do you think something else is needed?
>
> You also include the whole story on how to do this, which is the same =20=

> (at least as far as I remember) as in RFC 2782. I think a reference is =
=20
> sufficient, especially since there is no pressing need that the actual =
=20
> calculation happens in this particular way.

well, the goal here is to simplify the reading and not forcing the =20
reader to look for that in the other doc...

>
>>> I'm slightly worried about using so many random numbers, is there =20=

>>> anyone who knows how hard those are to generate?
>
>> i couldn't find another mean to include the weight distribution in =20=

>> any other way.... do you have any ideas of howw to include a =20
>> probability distribution without using random numbers?
>
> :-)
>
> That would be cool, wouldn't it?
>
> Actually, for this purpose there is no real reason for the numbers to =20=

> be truly random, as long as their distribution is fairly even and =20
> different instances of an implementation don't all start with the same =
=20
> value.

yes pseudo random number would be acceptable i guess

i can change this

> So a random seed and a counter would work equally well. And if you use =
=20
> random numbers, you need more random bits as the weight values get =20
> more precise. For instance, if A and B have weights 1 and 3, then you =20=

> need two random bits. If A is 1023 and B 3073 then you need 12, but it =
=20
> seems rather ridiculous to specify weights this precisely.
>

the weigth is only one octet, so maximum 255 i guess, but anyway, i =20
agree that having high weights doesn't make much sense in any case...

>>> One way to do this would be to translate as many decisions as =20
>>> possible into a numbers or bit mapped flags which can be compared =20=

>>> much more easily.
>
> [...]
>
>> this seems promising...
>
>> anyway, i guess we should first try to agree on what factors need to =20=

>> be taken into account and then we can try to summarize them using =20
>> this type of technique.
>
> Yes.
>
>> Moreover, i would propose that we still keep the expalantion of all =20=

>> the factors in the document and we also include this type of rules =20=

>> because it is true that this type of rules result in an optimized =20
>> implementation, it is also true that they are more obscure than the =20=

>> set rules. So i would keep the rules to make the understanding of =20
>> what is going on easier...
>
> Agree. However, don't forget that the way something is explained in a =20=

> draft will be the default way it is implemented unless there are =20
> important reasons to do it otherwise.
>

yes, but my idea was to, once we agree on the rules, include in the =20
draft some implementations guidelines, describing this type of formulas =20=

that you suggest that summarize a set of rules...

>> in other words, there are two issues here that i think are somehow =20=

>> different:
>> - on one hand there is the complexity due to the amount of factors =20=

>> that need to be considered
>> - on the other hand is the complexity of implementing all the =20
>> resulting rules
>
> Right.
>
>>> 1: src =3D=3D dst??? Either this is a mistake and you mean something =
=20
>>> like src1 =3D=3D src2 or I seriously don't get it
>
>> this basically means that if you have two (src,dst) address pairs, =20=

>> one being (IPA,IPA) and the other being (IPB,IPC) then you prefer =20
>> (IPA,IPA)
>
>> i guess this is not very useful in general but only in the specific =20=

>> case that you are trying to communicate with the local host...
>
> I think if you need to multihome make communication with the local =20
> host more reliable you have problems that are bigger than what we can =20=

> fix with smart locator pair selection.  :-)
>

:-)

> I don't see any reason to keep this rule.

i have no strong preference here, i can remove this one

>
>>> 3: isn't this covered by the notion of being locally operational?
>
>> i don't think so, because one thing is that a given address is =20
>> locally non operational and another thing is that a address pair is =20=

>> non operational. I mean, two locally operational addresses may =20
>> perfectly result in a non operational address pair (because the path =20=

>> is broken)
>
> Yes, but can we know this before the pair is tested with a probe? That =
=20
> seems unlikely.
>

agree
but then you create all the potentially reachable locator pairs using =20=

the locally operational addresses and then you try them to figure out =20=

which of those are actually reachable.

So you discard the non locally operational addresses from the start and =20=

then you probe with the the others to see which ones are actually =20
working

>>> 5: may overrule priority information, I think we want this in some =20=

>>> way but this is probably too simple (note that I talk about stopping =
=20
>>> address pair exploration for addresses / pairs with equal or lower =20=

>>> preference but continue for ones with higher preference)
>
>> i am not sure i am following this...
>
>> note that this needs to be started at soem point, meaning that at the =
=20
>> begining, all address pairs will be in unknown state, so this rule =20=

>> will not apply. So, this means that address pairs with high =20
>> preference will be explored and at this point some of these will be =20=

>> know to be operational. So after that, the ones that are operational =20=

>> will be preferred over those that are not.
>
> What I'm afraid of is that a context may rehome several times in quick =
=20
> succession because of this rule... That would be suboptimal.

indeed, but i fail to see how this would happen...
i mean you will only try to change after a failure has been detected, =20=

right? so if no failure is detected, no rehoming, independetly of what =20=

the rules for the preferred locator pair to use next states...

>
>>> 6 and 7: shouldn't addresses of different families or scope be =20
>>> procluded from pairing up in the first place? (Although there are =20=

>>> some corner cases where different scopes may work.)
>
>> well this may be an approach, but current rfc3484 follows this type =20=

>> of approach allowing forming address pairs with different scope, but =20=

>> we could do otherwise....
>
> I have to read the latest version the "main" shim protocol draft =20
> before Montreal so maybe this is in there or maybe not... But wouldn't =
=20
> a dicussion on which address scopes are appropriate for shim6 be more =20=

> at home in the main document?
>

i don't think this is mentioned in the shim protocol document... it was =20=

mentioned once upon a time in the failure detection protocol, but not =20=

sure if it there still

> There is a lot to be said for limiting shim operations to global =20
> unicast addresses only, but I'm afraid that's too simple: it could be =20=

> very useful to be able to use the shim on unique site locals in the =20=

> cases where two sites have a private interconnect so they can reach =20=

> each other using this type of addresses.
>

agree

> However, I don't see how using any kind of ambiguous addresses, such =20=

> as link locals or old school site locals can work reliably.
>

may agree with this too

i don't have a problem eliminating site and link local addresses form =20=

here
>
>
>>> 9: this is unnecessary.
>
>> why?
>
>> i thing avoiding deprecated addresses may be useful...
>
> I don't. Either deprecated addresses work, so we use them, or they =20
> don't work, so we don't use them. No special case handling required.
>

but if they are deprecated, they may stop working anytime soon, right? =20=

(for some definition of anytime)

>>> 10 and 11: it's becoming unclear to me how this list works. In BGP =20=

>>> you enter with a list of items and continue with the ones that "win" =
=20
>>> a rule until you're left with one and that's the best one so you =20
>>> choose that one. Another way to approach such a list is "if (r1 && =20=

>>> r2 ... r16 && r17) then use this pair" where the pairs are =20
>>> pre-sorted for preference, but you seem to mix the two approaches =20=

>>> here.
>
>> i am not sure i understand...
>
>> the draft states that
>
>>    The goal of the defualt locator-pair selection algorithm is to
>>    produce an ordered list of locator pairs to be tried for rehoming =20=

>> an
>>    ongoing communication.  The ordered list can be produced with any
>>    sorting algorithm.  The set of rules described next are the
>>    comparison criteria to be used in the locator-pair sorting =20
>> algorithm.
>>    This rules act must be processed in order and if a given rule =20
>> selects
>>    a locator pair over the other one, then the following rules don't
>>    need to be processed and the selected locator pair is prefered.
>
>> do you think that the described set of rules can be used as a =20
>> comparison criteria for a sorting algorithm?
>
> Ok, this is the BGP style of rule processing. Upon rereading the list =20=

> of rules I see that this should work. However, some of the "prefer" or =
=20
> "avoid" rules should really be "only accept" or "never use" rules, =20
> such as don't mix address families and don't mix scopes.

with families i agree

with scopes, mixed scopes may work

>
> Maybe there should be a separate list of rules for creating address =20=

> pairs where these rules could go so that the preference rules can work =
=20
> as they are written now?
>

in the creation of the candidate set perhaps?

> Or do you want to stick to preferring the same address family or scope =
=20
> but also allowing mixing those?
>

for versions i agree, for scopes i am not sure...

>>> 12: I think this is inappropriate here. Yes, there should be a way =20=

>>> to prefer temporary addresses, but this is a policy setting on most =20=

>>> systems so it shouldn't be hardcoded into shim6 or something related =
=20
>>> to shim6.
>
>> this is also included in rfc3484 i think and in the case of a locator =
=20
>> selection for the shim, it makes more sense to use a temp address as =20=

>> oposed to the rfc3484 case, where you usually want to prefer a public =
=20
>> address.
>
> First of all, I don't think it's a good idea to copy a rule just =20
> because it's in a different place as well. This only makes it harder =20=

> to get rid of it when it turns out it was not a good rule.
>

well, actually in this case, the rule is exactly the oposite...

> Second, _using_ temporary or non-temporary addresses isn't all that =20=

> interesting in our case, it's _disclosing_ those addresses to the =20
> other side that's important. So to be true to the intent of RFC 3041 =20=

> we should make sure we only include temporary addresses in the locator =
=20
> set that we send to the other side during shim negotiations.
>

yes, you are right... we have talked about including some comment about =20=

this in the shim protocol document...

so would you say that once that the temp addresses have been included =20=

in the locator set, we don't need to make a distinction when selecting =20=

the address? i.e. remove this rule and only leave the cosniderations =20
about including temp addresses in the locator sets?

>> I mean i agree that more cosnideration needs to be taken about which =20=

>> temp addresses are included in the candidate set, but i think this is =
=20
>> needed in addition to this rule rather than instead of this rule...
>
> I think in the spirit of limiting the number of rules this is one that =
=20
> doesn't really buy us much so there is no reason to include it.
>

ok, i guess this answer my question above :-)

i may agree with this...

>>> A better way to handle this would be to take temporary yes/no into =20=

>>> consideration when building the LOL. Note that generally, a host =20
>>> will have a temporary and a regular address in the same prefix. The =20=

>>> two of those would be equivalent for the purposes of shim6 so =20
>>> there's no need to include both.
>
>> that makes sense
>> but are you suggesting that a host that has temp addresses will =20
>> generate both public and temp addresses for each prefix and that it =20=

>> won't use both types in a single context? this may make sense, but i =20=

>> am not sure we want to hardcode this as the default behaviour...
>
> I think this would be the right thing to do, but in that case it's =20
> important to be able to determine which addresses are the temporary =20=

> and non-temporary equivalents.
>
>>> 17: may want to make this one of the first rules after making sure =20=

>>> there is reachability.  :-)
>
>> this is when you need to select a locator pair after a failure, i =20
>> guess so this rule would result in returning to the ulid pair once =20=

>> that the alternative locator pair that is being used fails... but we =20=

>> can remove this one...
>
> No, it's a good rule, it's just that I would go back to the ULIDs =20
> unless there is a very big reason to avoid them, not have this rule =20=

> sit at the very end as kind of a tie breaker.
>

ok, where would you put it?

regards, marcelo

>>> What about making sure we only use source addresses that we know the =
=20
>>> correspondent knows we have, and/or are covered by HBA?
>
>> or cga...
>
>> but this verification is needed in order to be part of Ls(peer), =20
>> according to the shim prtocol, but we can include a comment about =20
>> this in the security considerations section...
>
> Ok.
>
> Iljitsch
>

Delivery-date: Thu, 29 Jun 2006 10:53:13 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: reachability also for non-shim protocols
Date: Thu, 29 Jun 2006 12:53:03 +0200
To: marcelo bagnulo braun <[email-masked]>

On 29-jun-2006, at 12:33, marcelo bagnulo braun wrote:

>> 4. Schedule probes, considering exponential backoff

>> 5. When packets are received, update 2

>> 6. Choose an address pair and perform a return routability check

> this is funny, i would say that probes of step 4,5 could be used  
> for this...

You're going way too fast.  :-)

>> Step 1 must be done by the client protocol, and if it supports  
>> preferences, those will probably be per session rather than the  
>> same for all sessions.

> yes, but again, there are two aspects here.

> on one hand we have the protocol specific preferences, like the  
> locator preferences options of shim6
> then we have that each protocol may have different usage for  
> different type of addresses, like preffering temp over stabel  
> addresses and so on

Right.

>> For step 2 there is no client protocol specific information so it  
>> can be done host-wide.

> well, different hosts may decide to include different locators sets  
> in the contexts, so the list will vary depending on the particular  
> context, and particular protocol, right?

Yes, but I'm assuming by this point there is a big fat list of  
address pairs, where some address pairs may only be of interest to  
one client protocol but others may be used by more than one client  
protocol.

>> It's also very useful to include information from other sessions,  
>> contexts and client protocols, including upper layer feedback. For  
>> instance, if a host has two addresses and a dozen of sessions tied  
>> to each, and suddenly there are problems with stuff tied to  
>> address 1 but not address 2, it makes sense to avoid pairs with  
>> source address 1.

> right, but maybe the sessions have different sets of addresses, so  
> the addresses available for one session are not available for the  
> other one. In this case, you need to probe with different addresses  
> for different sessions...

I don't think I understand...

>> 6 is again something that must happen in the client protocol. In  
>> theory, making sure the other side is who we think it is can be  
>> done for more than one client protocol at the same time (this is  
>> what I tried to accomplish in http://www.muada.com/drafts/draft- 
>> van-beijnum-shim6-reach-detect-00.txt which the secretariat still  
>> hasn't posted...) but in practice that is the firewall problem,  
>> which can make it such that a certain path is usable for one  
>> client protocol, but not for another, because the second one is  
>> filtered out by a firewall.

> but this is the case for all the probes imho

Sure, but if a firewall filters ALL shim packets then you don't have  
a problem because you're simply not going to be using shim6. The  
problems start when you can negotiate shim6 but not send probes or  
some other combinations of parts that work and other parts that don't.

> i mean, you can use the probes as a return routability test.

The point here is that in order to be able to trust a return  
routability test, this must be something encapsulated in the client  
protocol. So maybe A1<->B1 works for proto=shim, but not for proto=mip.

> I guess that what you are proposing is to make the probing using a  
> general protocol and then perform a return routability check using  
> the client protocol specific encapsulation in order to verify if  
> the particular client protocol is filtered by the firewall.

Right!

> The other option is to perform the probes using the client protocol  
> encpasulation and then you don't need to perform the additional  
> return routability. The trade off here is that you do a joint path  
> exploration for all protocols but you need an additional return  
> routability check per client protocol (and the added complexity of  
> coordinating among protocols...) i am not sure is worth it

Well if you read on you'll see that I wrote:

>> So the return routability check must be performed by each client  
>> protocol itself. Considering all the ways in which this can go  
>> wrong, performing the return routability checks involves most of  
>> the complexity of probing reachability in the first place, so we  
>> must invoke the end-to-end principle which I think applies in the  
>> following way: if all cient protocols must do all this work  
>> themselves anyway, having another instance of the same mechanism  
>> in the middle serves no purpose.

In other words: nice idea, shame about the firewalls that make in  
unusable in practice.

But essentially, every communciation where we send something and the  
other side sends something back where we can determine which  
addresses we used in our packet and that this wasn't too long ago,  
can serve as a probe. So if an address pair works for MIP, we know  
it's extremely likely it will work for shim as well so we only need  
to make sure by sending a probe in shim encapsulation. The other way  
around, if a shim probe for a certain address pair has timed out, it  
makes much more sense for mip to try other pairs first as it's  
unlikely that this pair will work for mip but not for shim.

So a good use of hints makes having a shared probing protocol mostly  
unnecessary.

Delivery-date: Thu, 29 Jun 2006 10:51:18 +0000
Date: Thu, 29 Jun 2006 13:50:57 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Iljitsch,

> One way to address this is to split the reachability detection into a 
> shim-specific part (the keepalives) and a generic part (the path 
> exploration), so that the generic part can evolve independent of shim6.
>
> Note that I'm not saying this is necessarily the path we should take, 
> but seeing that there is other stuff that can also benefit from 
> reachability detection, it certainly seems prudent to think about 
> this now while we still have the opportunity to easily go into 
> another direction.

It would be great if we could do something like this,
but it seems that the employment of multiple different
protocols (in the protocol number/port number sense)
could lead to a situation where exploration says we have
connectivity but Shim6 says we don't. I'd like to avoid that.

>> But many
>> scenarios that I can see do not necessarily work well with ICMP,
>> particularly with one version of ICMP. In MOBIKE, for instance,
>> it would have been inappropriate to use anything else than the
>> regular NAT-T UDP at the bottom, because only that can show
>> whether actual MOBIKE/IKEv2/IPsec traffic will get through. And
>> what about HIP running over IPv4?
>
>
> Since we're determining unidirectional reachability, NAT is not 
> actually as big a problem as it would ordinarily seem. The big issue 
> with NAT is making sure that both ends know the addresses on both 
> sides and there are translation rules that allow incoming packets to 
> be delivered. But you're right ICMP won't work with NAT, we'd have to 
> use UDP for that. But I guess it would make sense to develop a non-
> NAT IPv6 version first and then see what needs to be done to make it 
> work over IPv4 with NAT.

In a sense, that is what we are doing -- developing the IPv6 and Shim6
version
of the reachability protocol. With the knowledge that it is insufficient
for,
say, HIP use with NATs and IPv4. The question is if the separation into
two components or the use of ICMPv6 makes future use in other contexts
easier. Frankly, I don't know if that's the case.

>> But as a general rule, I'd like to
>> get a working, as simple as possible Shim6 mechanism out there.
>> Even if its not optimized for all situations. We can work on  extensions
>> like fate sharing between contexts later, too.
>
>
> I disagree with that approach, I think we should make the first 
> version as good as it can be. I don't see much added value in 
> finishing this work a little earlier, we're obviously too late to 
> avoid PI in IPv6 now (if that can be avoided it won't be because of 
> shim6) or avoid having legacy non-shim IPv6 implementations out 
> there, but at the same time IPv6 isn't deployed on any measurable 
> scale yet so there is still (some) time.

I agree that we do not need to ship Shim6 this month. But efforts like
this have a best-before date in any case. At some point the interest
in implementations and WG contribution is going to go down, if we
don't deliver a spec that people can start to play with.

>> Was there other issues related to probe storms? We do have
>> exponential back-off.
>
>
> Not really. There is no description of how this works.

The newest drafts do have some description of it. Take a look
to see if its sufficient.

>
>>> Another thing that's missing completely from this draft is a
>>> discussion of how to use address pair preference information. This
>>> makes it impossible to address traffic engineering needs.
>>
>
>> This is important, but can be addressed separately.
>
>
> No, that would make it MUCH harder, as this will only work well if 
> both ends implement it. And we're getting flack for not paying 
> attention to traffic engineering as it is.

OK. (But separately != optional). If you think we need it
from day one, lets do it.

>>> Data packets as opposed to what other types of packets?
>>
>
>> I added a clarification. Basically, its all packets including both
>> ULP packets and SHIM6 control messages, but NOT keepalives
>> or probes.
>
>
> I think it's a good idea to consider TCP ACKs with no user data as 
> non-data packets that don't need to generate return traffic as well.

Hmm... in order for that to be useful (as an optimization), it would
have to be
supported by both sides. That would set a requirement that the shim layer
can peek inside the TCP packets. Not sure if we want to do that.

>>> So when we receive a keepalive from the other side, _we_ stop sending
>>> keepalives? This may be the right thing to do, but it's not obvious
>>> to me why. Some explanation would help.
>>
>
>> Keepalives are only used if there's one-way communication. Since the
>> other side sends a keepalive, its not sending anything else at that
>> time. Hence we have no need for keepalives.
>
>
> But do we need this rule? It may make implementations more complex 
> without any benefit.

Assuming we want to avoid keepalives for periods of bidirectional
communication or silence, I think we do need it. If you send a keepalive
based on a keepalive, you don't have a termination condition.

> Why not leave it up to the implementers? If we say that after 10 
> seconds the full path exploration starts, implementers are free to 
> experiment with what works well (3, 4, 8 seconds between keepalives) 
> without any need to revisit the spec.

I have now made it clear that these are recommended defaults,
but that more experimentation is needed to determine the best
values. And that implementations can choose what they want to
do.

>>> I believe that since the id of the last received probe is included,
>>> the iseeyou flag is unnecessary.
>>
>
>> But we also have the case where you report seeing data packets but
>> no probes.
>
>
> Good point. But couldn't that be solved by using a special value for 
> the last seen id?

Sure. Its just a question of how to encode that information in the
bits.

>>> Although copying back the last seen id seems to do the job, I can't
>>> help but feel that it would be preferable to add timers to reach
>>> round trip times and copy back more received ids and also sent ids.
>>> This allows the receiver of a probe to determine which of the probes
>>> that made it to the other side did so faster, so it can select the
>>> address pair with the shortest round trip time.
>>
>
>> Right. But all that can go into extensions. I'd like to have the
>> minimum necessary to get this spec done.
>
>
> Let's split the difference and specify the fields, but make (most of) 
> their use optional.
>
> I severely dislike having fixed length data in TLV format, because 
> that makes parsing much harder. If you look at Van Jacobson's work 
> with TCP you'll see that a fixed header allows extremely streamlined 
> implementations.

If we move the current option contents to the messages (as discussed
earlier),
this will simplify things a bit. I think we need to retain TLVs for the
rest, because
that allows multiple appearances of the same value (e.g. reception
report) and
future extensibility.

Re: timer values etc. I don't currently have a good idea of what the
behaviour based on these fields would be. Maybe you do.

>>> Including sent ids along with the addresses the probe with that id
>>> was sent to helps the receiver determine that some probes didn't make
>>> it (yet). If a probe didn't work in one direction of an address pair,
>>> it's reasonable to assume that it may also not work in the other
>>> direction and try other pairs first.
>>
>
>> True as well, but again perhaps material for future
>> optimizations.
>
>
> I really like having multiple ids for earlier probes in there, it 
> should cut down on the number of packets exchanged, and I also 
> suspect that there could be race conditions when certain packets are 
> lost and not others so that an implementation that only echos the 
> last seen id may stay in an oscillating state, but I haven't been 
> able to think of an example so far.

The spec says it should return multiple identities, everything that it
has recently seen
(up to some reasonable limit).

--Jari

Delivery-date: Thu, 29 Jun 2006 10:33:37 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: reachability also for non-shim protocols
Date: Thu, 29 Jun 2006 13:33:34 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 26/06/2006, a las 21:51, Iljitsch van Beijnum escribi=F3:

> I've been thinking a bit more about the issues with making the =20
> reachability detection protocol more general so it can be used for =20
> protocols other than shim6 as well. I'll be calling shim6 and other =20=

> protocols that are interested in reachability "client protocols".
>
> The whole process of rehoming to a new address pair can be broken up =20=

> in several parts:
>
> 1. Make a list of individual addresses / address pair under =20
> consideration ordered by preference
>

yes, but preference information can be in may forms, considering local =20=

policy, peer policy, temp vs public add, HoA vs CoAs and so on...

so i guess that all this needs to be integrated in a single list

> 2. Order available address pairs by likelihood of being reachable
>

again there are multiple sources for this information, local, remote, =20=

e2e

same here, we need to integrate all this information in a single list =20=

(which imho is simpler thant the previous case...)

> 3. Integrate 1 and 2 into a single ordered lists of address pairs =20
> (order of subsequent probing)
>
> 4. Schedule probes, considering exponential backoff
>
> 5. When packets are received, update 2
>
> 6. Choose an address pair and perform a return routability check
>

this is funny, i would say that probes of step 4,5 could be used for =20
this...

> Step 1 must be done by the client protocol, and if it supports =20
> preferences, those will probably be per session rather than the same =20=

> for all sessions.
>

yes, but again, there are two aspects here.

on one hand we have the protocol specific preferences, like the locator =20=

preferences options of shim6
then we have that each protocol may have different usage for different =20=

type of addresses, like preffering temp over stabel addresses and so on

> For step 2 there is no client protocol specific information so it can =20=

> be done host-wide.

well, different hosts may decide to include different locators sets in =20=

the contexts, so the list will vary depending on the particular =20
context, and particular protocol, right?

>  It's also very useful to include information from other sessions, =20
> contexts and client protocols, including upper layer feedback. For =20
> instance, if a host has two addresses and a dozen of sessions tied to =20=

> each, and suddenly there are problems with stuff tied to address 1 but =
=20
> not address 2, it makes sense to avoid pairs with source address 1.
>

right, but maybe the sessions have different sets of addresses, so the =20=

addresses available for one session are not available for the other =20
one. In this case, you need to probe with different addresses for =20
different sessions...

> It doesn't matter too much how 3, 4  and 5 happen, although ideally, =20=

> scheduling happens host-wide so synchronization and temporary =20
> congestion are avoided.
>
> 6 is again something that must happen in the client protocol. In =20
> theory, making sure the other side is who we think it is can be done =20=

> for more than one client protocol at the same time (this is what I =20
> tried to accomplish in =20
> http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect=20
> -00.txt which the secretariat still hasn't posted...) but in practice =20=

> that is the firewall problem, which can make it such that a certain =20=

> path is usable for one client protocol, but not for another, because =20=

> the second one is filtered out by a firewall.

but this is the case for all the probes imho

i mean, you can use the probes as a return routability test.
I guess that what you are proposing is to make the probing using a =20
general protocol and then perform a return routability check using the =20=

client protocol specific encapsulation in order to verify if the =20
particular client protocol is filtered by the firewall.

The other option is to perform the probes using the client protocol =20
encpasulation and then you don't need to perform the additional return =20=

routability. The trade off here is that you do a joint path exploration =20=

for all protocols but you need an additional return routability check =20=

per client protocol (and the added complexity of coordinating among =20
protocols...) i am not sure is worth it

regards, marcelo

>
> So the return routability check must be performed by each client =20
> protocol itself. Considering all the ways in which this can go wrong, =20=

> performing the return routability checks involves most of the =20
> complexity of probing reachability in the first place, so we must =20
> invoke the end-to-end principle which I think applies in the following =
=20
> way: if all cient protocols must do all this work themselves anyway, =20=

> having another instance of the same mechanism in the middle serves no =20=

> purpose.
>
> However, there is synergy to be had and congestion to be avoided by =20=

> sharing the reachability detected by other protocols as hints. The =20
> trikcy part is figuring out how this should happen. I want to say =20
> "API" but how many APIs can we stand to have? And because all/most of =20=

> this happens in the kernel, it should be possible for implementers to =20=

> do the right thing without any guidance from us. Or maybe not. I don't =
=20
> know.
>
> It would be worthwhile to separate the specification into a =20
> shim-specific and non-shim-specific part to promote code reuse, =20
> though.
>
> Thoughts?
>

Delivery-date: Thu, 29 Jun 2006 10:30:37 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: draft-ietf-shim6-locator-pair-selection-00.txt
Date: Thu, 29 Jun 2006 12:29:36 +0200
To: marcelo bagnulo braun <[email-masked]>

On 28-jun-2006, at 13:15, marcelo bagnulo braun wrote:

>> Note that this draft overlaps to a large degree with http:// 
>> www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt  
>> (STILL not posted by the secretariat 8 days after the fact...)

> ok, i will comment on this draft in a separate email, but we should  
> probably try to produce a single document then...

I'm not sure though that your locator pair selection draft should be  
a separate document... Maybe it's better to integrate it with the  
failure/reachability detection document.

>> Also, just before section 2.2 the text ends and without  
>> introduction, there is a formula. It is not immediately obvious  
>> that this formula means the same thing as the preceding paragraph.

> strange... actually the attempt was that the formula is the exact  
> formalization of the previous paragraph... do you think there is a  
> mistake?

No, that's not what I wanted to say. What I mean is: it's not obvious  
that the formula IS the same thing as what's said in the paragraph.  
So you may want to say explicitly that the formula expresses the same  
thing as the text so people won't be confused.

> or just that a sentence like "this means that the candidate locator  
> pair set can be constructed as follows" would be enough?

If you say it in that way people may still think the formula means  
something different than the text. The point is that if you  
understand the text you don't have to spend time trying to figure out  
what the formula means as long as you know it means the same thing as  
the text.

>> I don't think using LOLs(peer) is a good choice, because this  
>> assumes that we always know what the LOLs for the peer are,  
>> without regard to the process of communicating the set back and  
>> forth or the possibility that a peer may not disclose all of its  
>> LOLs. Another name for this would be better.

> but the draft defines:

>    We define the local set of locally-operational locators (LOLs 
> (local))
>    as the local locators that are included in the local locator set
>    (Ls(local) as defined in [1]) and that are locally operational as
>    defined in [2].  Locally operational addresses are discovered  
> through
>    local means that are outside of the scope of this document.

> so the definition states that these are not all the operational  
> addresses (not for the peer nor for the local host) but the  
> operational addresses that are included in the particular context

Sure, but it's still not the best possible name.

>> I'm not sure if reachable/unknown/unreachable is expressive  
>> enough, maybe it's better to express this as a more gliding scale.  
>> I'm not sure yet, though.

> well, there is also the age of the reachability information  
> considered, making a scale among locator pairs for which a  
> reachability information is available... what else would you  
> include in this scale?

I would also take the preference values and maybe scope and create  
one value that can be used to rank locator pairs.

It seems obvious to say something is reachable or unreachable, but  
the problem is that you never really know for sure, because thins can  
have changed since the last probe. So it's important to add a  
confidence level, which would be the age of the reachable/unreachable  
information. But that's two values, you can wrap that into one by  
making reachable 100% and unreachable -100% and over time regress to  
0% if no newer information becomes available.

>> I see you copied the weight calculation from the SRV RFC. Wouldn't  
>> it be easier just to say what the results should be and refer to  
>> this RFC for an example?

> well, actually the draft states:

>   The weight field express the relative weight for locators with the
>    same priority, and as defined in [8] larger weights should be  
> given a
>    proportionally higher probability of being selected.

> being

>    [8]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
>         specifying the location of services (DNS SRV)", RFC 2782,
>         February 2000.

> do you think something else is needed?

You also include the whole story on how to do this, which is the same  
(at least as far as I remember) as in RFC 2782. I think a reference  
is sufficient, especially since there is no pressing need that the  
actual calculation happens in this particular way.

>> I'm slightly worried about using so many random numbers, is there  
>> anyone who knows how hard those are to generate?

> i couldn't find another mean to include the weight distribution in  
> any other way.... do you have any ideas of howw to include a  
> probability distribution without using random numbers?

:-)

That would be cool, wouldn't it?

Actually, for this purpose there is no real reason for the numbers to  
be truly random, as long as their distribution is fairly even and  
different instances of an implementation don't all start with the  
same value. So a random seed and a counter would work equally well.  
And if you use random numbers, you need more random bits as the  
weight values get more precise. For instance, if A and B have weights  
1 and 3, then you need two random bits. If A is 1023 and B 3073 then  
you need 12, but it seems rather ridiculous to specify weights this  
precisely.

>> One way to do this would be to translate as many decisions as  
>> possible into a numbers or bit mapped flags which can be compared  
>> much more easily.

[...]

> this seems promising...

> anyway, i guess we should first try to agree on what factors need  
> to be taken into account and then we can try to summarize them  
> using this type of technique.

Yes.

> Moreover, i would propose that we still keep the expalantion of all  
> the factors in the document and we also include this type of rules  
> because it is true that this type of rules result in an optimized  
> implementation, it is also true that they are more obscure than the  
> set rules. So i would keep the rules to make the understanding of  
> what is going on easier...

Agree. However, don't forget that the way something is explained in a  
draft will be the default way it is implemented unless there are  
important reasons to do it otherwise.

> in other words, there are two issues here that i think are somehow  
> different:
> - on one hand there is the complexity due to the amount of factors  
> that need to be considered
> - on the other hand is the complexity of implementing all the  
> resulting rules

Right.

>> 1: src == dst??? Either this is a mistake and you mean something  
>> like src1 == src2 or I seriously don't get it

> this basically means that if you have two (src,dst) address pairs,  
> one being (IPA,IPA) and the other being (IPB,IPC) then you prefer  
> (IPA,IPA)

> i guess this is not very useful in general but only in the specific  
> case that you are trying to communicate with the local host...

I think if you need to multihome make communication with the local  
host more reliable you have problems that are bigger than what we can  
fix with smart locator pair selection.  :-)

I don't see any reason to keep this rule.

>> 3: isn't this covered by the notion of being locally operational?

> i don't think so, because one thing is that a given address is  
> locally non operational and another thing is that a address pair is  
> non operational. I mean, two locally operational addresses may  
> perfectly result in a non operational address pair (because the  
> path is broken)

Yes, but can we know this before the pair is tested with a probe?  
That seems unlikely.

>> 5: may overrule priority information, I think we want this in some  
>> way but this is probably too simple (note that I talk about  
>> stopping address pair exploration for addresses / pairs with equal  
>> or lower preference but continue for ones with higher preference)

> i am not sure i am following this...

> note that this needs to be started at soem point, meaning that at  
> the begining, all address pairs will be in unknown state, so this  
> rule will not apply. So, this means that address pairs with high  
> preference will be explored and at this point some of these will be  
> know to be operational. So after that, the ones that are  
> operational will be preferred over those that are not.

What I'm afraid of is that a context may rehome several times in  
quick succession because of this rule... That would be suboptimal.

>> 6 and 7: shouldn't addresses of different families or scope be  
>> procluded from pairing up in the first place? (Although there are  
>> some corner cases where different scopes may work.)

> well this may be an approach, but current rfc3484 follows this type  
> of approach allowing forming address pairs with different scope,  
> but we could do otherwise....

I have to read the latest version the "main" shim protocol draft  
before Montreal so maybe this is in there or maybe not... But  
wouldn't a dicussion on which address scopes are appropriate for  
shim6 be more at home in the main document?

There is a lot to be said for limiting shim operations to global  
unicast addresses only, but I'm afraid that's too simple: it could be  
very useful to be able to use the shim on unique site locals in the  
cases where two sites have a private interconnect so they can reach  
each other using this type of addresses.

However, I don't see how using any kind of ambiguous addresses, such  
as link locals or old school site locals can work reliably.

>> 8: mentions locator pair table, but this isn't defined in the  
>> draft, probably needs a reference

> section 2.4.  Locator-pair selection table states

Ok. I searched for "pair table" but didn't find any other mentions...

>> 9: this is unnecessary.

> why?

> i thing avoiding deprecated addresses may be useful...

I don't. Either deprecated addresses work, so we use them, or they  
don't work, so we don't use them. No special case handling required.

>> 10 and 11: it's becoming unclear to me how this list works. In BGP  
>> you enter with a list of items and continue with the ones that  
>> "win" a rule until you're left with one and that's the best one so  
>> you choose that one. Another way to approach such a list is "if  
>> (r1 && r2 ... r16 && r17) then use this pair" where the pairs are  
>> pre-sorted for preference, but you seem to mix the two approaches  
>> here.

> i am not sure i understand...

> the draft states that

>    The goal of the defualt locator-pair selection algorithm is to
>    produce an ordered list of locator pairs to be tried for  
> rehoming an
>    ongoing communication.  The ordered list can be produced with any
>    sorting algorithm.  The set of rules described next are the
>    comparison criteria to be used in the locator-pair sorting  
> algorithm.
>    This rules act must be processed in order and if a given rule  
> selects
>    a locator pair over the other one, then the following rules don't
>    need to be processed and the selected locator pair is prefered.

> do you think that the described set of rules can be used as a  
> comparison criteria for a sorting algorithm?

Ok, this is the BGP style of rule processing. Upon rereading the list  
of rules I see that this should work. However, some of the "prefer"  
or "avoid" rules should really be "only accept" or "never use" rules,  
such as don't mix address families and don't mix scopes.

Maybe there should be a separate list of rules for creating address  
pairs where these rules could go so that the preference rules can  
work as they are written now?

Or do you want to stick to preferring the same address family or  
scope but also allowing mixing those?

>> 12: I think this is inappropriate here. Yes, there should be a way  
>> to prefer temporary addresses, but this is a policy setting on  
>> most systems so it shouldn't be hardcoded into shim6 or something  
>> related to shim6.

> this is also included in rfc3484 i think and in the case of a  
> locator selection for the shim, it makes more sense to use a temp  
> address as oposed to the rfc3484 case, where you usually want to  
> prefer a public address.

First of all, I don't think it's a good idea to copy a rule just  
because it's in a different place as well. This only makes it harder  
to get rid of it when it turns out it was not a good rule.

Second, _using_ temporary or non-temporary addresses isn't all that  
interesting in our case, it's _disclosing_ those addresses to the  
other side that's important. So to be true to the intent of RFC 3041  
we should make sure we only include temporary addresses in the  
locator set that we send to the other side during shim negotiations.

> I mean i agree that more cosnideration needs to be taken about  
> which temp addresses are included in the candidate set, but i think  
> this is needed in addition to this rule rather than instead of this  
> rule...

I think in the spirit of limiting the number of rules this is one  
that doesn't really buy us much so there is no reason to include it.

>> A better way to handle this would be to take temporary yes/no into  
>> consideration when building the LOL. Note that generally, a host  
>> will have a temporary and a regular address in the same prefix.  
>> The two of those would be equivalent for the purposes of shim6 so  
>> there's no need to include both.

> that makes sense
> but are you suggesting that a host that has temp addresses will  
> generate both public and temp addresses for each prefix and that it  
> won't use both types in a single context? this may make sense, but  
> i am not sure we want to hardcode this as the default behaviour...

I think this would be the right thing to do, but in that case it's  
important to be able to determine which addresses are the temporary  
and non-temporary equivalents.

>> 17: may want to make this one of the first rules after making sure  
>> there is reachability.  :-)

> this is when you need to select a locator pair after a failure, i  
> guess so this rule would result in returning to the ulid pair once  
> that the alternative locator pair that is being used fails... but  
> we can remove this one...

No, it's a good rule, it's just that I would go back to the ULIDs  
unless there is a very big reason to avoid them, not have this rule  
sit at the very end as kind of a tie breaker.

>> What about making sure we only use source addresses that we know  
>> the correspondent knows we have, and/or are covered by HBA?

> or cga...

> but this verification is needed in order to be part of Ls(peer),  
> according to the shim prtocol, but we can include a comment about  
> this in the security considerations section...

Ok.

Iljitsch

Delivery-date: Thu, 29 Jun 2006 07:45:46 +0000
Cc: 'shim6-wg' <[email-masked]>, 'Iljitsch van Beijnum' <[email-masked]>, Sam Xia <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Unidirectional Connectivity (was Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Thu, 29 Jun 2006 10:45:36 +0300
To: Jari Arkko <[email-masked]>

El 26/06/2006, a las 13:13, Jari Arkko escribi=F3:
> On point b, I'm not sure there is a lot we can do. At least not
> without revisiting some of the requirement decisions, such
> as the need to support at least some scenarios where there's
> only unidirectional connectivity.
>
> Thoughts?
>

i guess that the main reason to support unidirectional connectivity is=20=

ingress filters.
I mean, as far as i understand, failures affecting only one of the=20
directions in a path are kind of rare, so it probably the added=20
complexity is not worth it. However, if no additional mechanisms for=20
dealing with ingress filtering are availalable, I guess that=20
unidirectional connectivity can be quite common.

Now, the solutions to deal with ingress filtering seem to also imply=20
quite a few changes in the sites, and it is not so straight forward=20
that sites would like that.

So i guess that the options are either complexity to deal with ingress=20=

filtering or complexity to deal with unidirectional paths...

OTOH, ingress filtering compatibility is also required for non-shim=20
capable hosts within multihomed sites...

So, i think we should have at least the option to support=20
unidirectional connectivity, but maybe we could define also a simpler=20
protocol that only verifies bidirectional connectivity for those sites=20=

that do implement ingress filtering compatibility mechanisms

Regards, marcelo

> --Jari
>
>

Delivery-date: Thu, 29 Jun 2006 07:34:33 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Thu, 29 Jun 2006 10:33:43 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 24/06/2006, a las 13:59, Iljitsch van Beijnum escribi=F3:

> On 22-jun-2006, at 16:59, marcelo bagnulo braun wrote:
>
>>> This draft works per-context exclusively. So if there are 2, 5 or 10=20=

>>> contexts between two hosts, this means 2, 5 or 10 times the amount=20=

>>> of work is done.
>
>> i agree that this would be a nice feature. the problem with this is=20=

>> how do you identify the peer in such a way that you can probe all the=20=

>> existing contexts.
>
> Have a look at the revision of my reachability detection draft:
> =
http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt
>
> Note that this is an update of draft-ietf-shim6-reach-detect-01.txt=20
> and it's not yet posted by the secretariat.
>

will provide feedback in a separate email...

>> The other option would be to use a single probe/keepalive for all the=20=

>> contexts between two peers. In order to do that we need a mean to=20
>> identify the peer so that the receiver of the packet can identify all=20=

>> the contexts corresponding to the same hosts and apply the received=20=

>> packet to all the contexts.
>
> Indeed.
>
>> BAsically this would introduce the notion of endpoint in the shim=20
>> context/protocol (which is not present today), since today the=20
>> granularity is ulid pairs (as oposed to endpoint pairs)
>
> Not necessarily, read my draft.
>
>> this would be a considerable change in the protocol i guess, but may=20=

>> be explored if people deem it relevant.
>
> It makes the protocol a bit more complex, but it does allow it to be=20=

> used by many different protocols at the same time.
>
>> As a general comment, i am kind of worried about the complexity of=20
>> the resulting protocol, including shim protoc and the failure=20
>> detection protocol and i would really preffer to try to simplify the=20=

>> protocol rather than making it more complex, even if this means=20
>> loosing some optimization for some cases.
>
> I suppose the case where there are multiple contexts between two host=20=

> won't be that common that it's worth too much effort to deal with it.=20=

> But if other protocols also need this, then it would be MUCH better to=20=

> have a single code base that's shared by all of them rather than have=20=

> essentially the same thing pop up in different places.
>
>> I am concerned about having a complex protocol that may become error=20=

>> prone (we already have feedback expressing this concern BTW)
>
> I hate complexity as much as the next IETFer, but leaving the last 10%=20=

> out just because it's simpler is generally not a good solution.

may agree with that
but my comment was more a observation rather than a wish... i mean imho=20=

we have already reached the reasonable complexity level for this=20
protocol (shim and faildet) and i would rather remove things rather=20
than add new ones...

>
>>>  However, it's important that there is fate sharing between the=20
>>> reachability protocol and the user protocol (shim in our case). I=20
>>> think this can be solved by having the quick reachability=20
>>> verification stuff (=3D FBD) encapsulated in the user protocol, but=20=

>>> let the full path exploration be a protocol of its own or live under=20=

>>> ICMPv6 or some such.
>
>> not sure why do you think this is needed. Defining the protocol=20
>> messages in a way that they can be included in the shim6 header as=20
>> well as in the mobility header or the hip header would be good enough=20=

>> to allow using the failure detection protocol in other protocols....=20=

>> what am i missing?
>
> See the discussion above, and the need for fate sharing between the=20
> reachability protocol and the "user" protocol. If we want the=20
> reachability detection to be shared by different users, then it can=20
> happen that one protocol is filtered and another isn't. So we probably=20=

> want the reachability detection to be independent of the "user"=20
> protocols and then when the reachability protocol says that something=20=

> is reachable, the user protocol does a quick check using its own=20
> protocol number to be sure it actually works.
>

yes, this is true

but otoh, the nice thing of carrying all the packets of a given=20
protocol wihtin the same header is that you know that either all=20
packets of the protocol are filtered or none of the them are. If you=20
use different header for different packets of the protocol, it may be=20
the case that e.g. the establishment packets make it but the keepalive=20=

packets are filtered, which is probably much worse than if all packets=20=

are filtered.

That is why, when i think about reusage of the faildet protocol i am=20
more thinking about reusing functionality rather than the packets=20
themselves.
I mean, i am not thinking about using the same packet exchange to=20
verify reachability for mip and for shim, but just using the same=20
protocol and packet format for both of them. The benefit comes form=20
that there is no need to design multiple protocols, not form not=20
needing to send multiple packets

regards, marcelo

Delivery-date: Wed, 28 Jun 2006 11:15:50 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-locator-pair-selection-00.txt
Date: Wed, 28 Jun 2006 14:15:13 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

thanks for the review and comments...

El 27/06/2006, a las 13:21, Iljitsch van Beijnum escribi=F3:
>
> Note that this draft overlaps to a large degree with =20
> http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect=20
> -00.txt (STILL not posted by the secretariat 8 days after the fact...)
>

ok, i will comment on this draft in a separate email, but we should =20
probably try to produce a single document then...

> I found some of the text a bit hard to follow, but it's hard to =20
> pinpoint exact problems, except maybe that you use weight and weight* =20=

> as different variables, which I don't like. How are you going to =20
> pronounce the second one??

actually i wanted to use weight' :-)

i will try to improve readability of the doc

>  Also, just before section 2.2 the text ends and without introduction, =
=20
> there is a formula. It is not immediately obvious that this formula =20=

> means the same thing as the preceding paragraph.

strange... actually the attempt was that the formula is the exact =20
formalization of the previous paragraph... do you think there is a =20
mistake? or just that a sentence like "this means that the candidate =20
locator pair set can be constructed as follows" would be enough?

>  Words to this effect or even letting the paragraph end in a colon =20
> rather than a period would help.
>
> I don't think using LOLs(peer) is a good choice, because this assumes =20=

> that we always know what the LOLs for the peer are, without regard to =20=

> the process of communicating the set back and forth or the possibility =
=20
> that a peer may not disclose all of its LOLs. Another name for this =20=

> would be better.
>

but the draft defines:

    We define the local set of locally-operational locators =
(LOLs(local))
    as the local locators that are included in the local locator set
    (Ls(local) as defined in [1]) and that are locally operational as
    defined in [2].  Locally operational addresses are discovered =
through
    local means that are outside of the scope of this document.

so the definition states that these are not all the operational =20
addresses (not for the peer nor for the local host) but the operational =20=

addresses that are included in the particular context

the situation is the following
the peer has a set of addresses S
the peer announces a subset of the set of addresses in a shim context =20=

Ls(peer)
now some of these addresses may be tagged with the broken flag in the =20=

locator preference option, which would be interpreted that these =20
locator a know to be locally not operational by the peer. the rest are =20=

the set of locators that the peer knows that they are locally =20
operational... of course, as you point out this does not imply that =20
these are all the locators that are locally operational for the peer, =20=

but it means that these are all the locators of the peer that are =20
locally operational for the peer in this particular context at this =20
point in time.

actually this is the same situation for the local locators, since the =20=

local host doesn't need to include all its locators in all its =20
contexts...

> I'm not sure if reachable/unknown/unreachable is expressive enough, =20=

> maybe it's better to express this as a more gliding scale. I'm not =20
> sure yet, though.
>

well, there is also the age of the reachability information considered, =20=

making a scale among locator pairs for which a reachability information =20=

is available... what else would you include in this scale?

I mean, what was considered in the document was that either the last =20
reachability test was successful or not and also the time elapsed since =20=

the last reachability test... would you consider additional =20
information?

> I see you copied the weight calculation from the SRV RFC. Wouldn't it =20=

> be easier just to say what the results should be and refer to this RFC =
=20
> for an example?
>

well, actually the draft states:

   The weight field express the relative weight for locators with the
    same priority, and as defined in [8] larger weights should be given =
a
    proportionally higher probability of being selected.

being

    [8]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

do you think something else is needed?

> I'm slightly worried about using so many random numbers, is there =20
> anyone who knows how hard those are to generate?
>

i couldn't find another mean to include the weight distribution in any =20=

other way.... do you have any ideas of howw to include a probability =20
distribution without using random numbers?

> I was slightlty shocked when I saw you have 17 rules.

me too!

>  I think this is way too many, hopefully this can be reduced.

fully agree

>  One way to do this would be to translate as many decisions as =20
> possible into a numbers or bit mapped flags which can be compared much =
=20
> more easily. Don't forget that math can easily be pipelined and =20
> parallelized in a modern CPU while if/thens can be detrimental to =20
> performance and make software harder to debug. Example of what I mean:
>
> preference =3D priority * 4096 + scope * 256 + weight * random[0-255]
>
> Maybe even divide by the number of seconds since the last successful =20=

> packet exchange...
>
> Scope can also be done as global =3D 1, site =3D 2, link local =3D 4, =
ipv4 =3D =20
> 8 then do a binary AND for source/dest and if the result !=3D 0 the =20=

> scopes are compatible, if =3D=3D 0, these addresses don't make for a =20=

> working pair.
>

this seems promising...

anyway, i guess we should first try to agree on what factors need to be =20=

taken into account and then we can try to summarize them using this =20
type of technique. Moreover, i would propose that we still keep the =20
expalantion of all the factors in the document and we also include this =20=

type of rules because it is true that this type of rules result in an =20=

optimized implementation, it is also true that they are more obscure =20
than the set rules. So i would keep the rules to make the understanding =20=

of what is going on easier...

in other words, there are two issues here that i think are somehow =20
different:
- on one hand there is the complexity due to the amount of factors that =20=

need to be considered
- on the other hand is the complexity of implementing all the resulting =20=

rules

of course, having a big set of rules will result in a complex =20
implementation

This approach that you are suggesting seems to simplify the second more =20=

than the first one and i think is a good idea, but i would rather first =20=

try to simplicy the first i.e. the amount of factors that need to the =20=

taken into account, first (as you do in the following comments)

> Now let's have a look at those 17 rules...
>
> 1: src =3D=3D dst??? Either this is a mistake and you mean something =
like =20
> src1 =3D=3D src2 or I seriously don't get it
>

this basically means that if you have two (src,dst) address pairs, one =20=

being (IPA,IPA) and the other being (IPB,IPC) then you prefer (IPA,IPA)

i guess this is not very useful in general but only in the specific =20
case that you are trying to communicate with the local host...

> 3: isn't this covered by the notion of being locally operational?
>

i don't think so, because one thing is that a given address is locally =20=

non operational and another thing is that a address pair is non =20
operational. I mean, two locally operational addresses may perfectly =20
result in a non operational address pair (because the path is broken)

> 5: may overrule priority information, I think we want this in some way =
=20
> but this is probably too simple (note that I talk about stopping =20
> address pair exploration for addresses / pairs with equal or lower =20
> preference but continue for ones with higher preference)
>

i am not sure i am following this...

note that this needs to be started at soem point, meaning that at the =20=

begining, all address pairs will be in unknown state, so this rule will =20=

not apply. So, this means that address pairs with high preference will =20=

be explored and at this point some of these will be know to be =20
operational. So after that, the ones that are operational will be =20
preferred over those that are not.

> 6 and 7: shouldn't addresses of different families or scope be =20
> procluded from pairing up in the first place? (Although there are some =
=20
> corner cases where different scopes may work.)
>

well this may be an approach, but current rfc3484 follows this type of =20=

approach allowing forming address pairs with different scope, but we =20
could do otherwise....

> 8: mentions locator pair table, but this isn't defined in the draft, =20=

> probably needs a reference
>

section 2.4.  Locator-pair selection table states

    We define the Locator-pair selection table to express preferences
    about which source address prefix to use when communicating with a
    given destination address prefix.  The table contains entries having
    a source prefix and a destination prefix each.  Given a locator =
pair,
    it is then possible to find a match when both the source prefix is
    contained in the source address and the destination prefix is
    contained in the destination address.

do you thing something else is needed?

> 9: this is unnecessary.
>

why?

i thing avoiding deprecated addresses may be useful...

could you expand on this?

> 10 and 11: it's becoming unclear to me how this list works. In BGP you =
=20
> enter with a list of items and continue with the ones that "win" a =20
> rule until you're left with one and that's the best one so you choose =20=

> that one. Another way to approach such a list is "if (r1 && r2 ... r16 =
=20
> && r17) then use this pair" where the pairs are pre-sorted for =20
> preference, but you seem to mix the two approaches here.
>

i am not sure i understand...

the draft states that

    The goal of the defualt locator-pair selection algorithm is to
    produce an ordered list of locator pairs to be tried for rehoming an
    ongoing communication.  The ordered list can be produced with any
    sorting algorithm.  The set of rules described next are the
    comparison criteria to be used in the locator-pair sorting =
algorithm.
    This rules act must be processed in order and if a given rule =
selects
    a locator pair over the other one, then the following rules don't
    need to be processed and the selected locator pair is prefered.

do you think that the described set of rules can be used as a =20
comparison criteria for a sorting algorithm?

> 12: I think this is inappropriate here. Yes, there should be a way to =20=

> prefer temporary addresses, but this is a policy setting on most =20
> systems so it shouldn't be hardcoded into shim6 or something related =20=

> to shim6.

this is also included in rfc3484 i think and in the case of a locator =20=

selection for the shim, it makes more sense to use a temp address as =20
oposed to the rfc3484 case, where you usually want to prefer a public =20=

address. Probably we could also define sets of temp addresses and =20
addresses belonging to different sets shouldn't be used in the same =20
communication...

I mean i agree that more cosnideration needs to be taken about which =20
temp addresses are included in the candidate set, but i think this is =20=

needed in addition to this rule rather than instead of this rule...

>  A better way to handle this would be to take temporary yes/no into =20=

> consideration when building the LOL. Note that generally, a host will =20=

> have a temporary and a regular address in the same prefix. The two of =20=

> those would be equivalent for the purposes of shim6 so there's no need =
=20
> to include both.

that makes sense
but are you suggesting that a host that has temp addresses will =20
generate both public and temp addresses for each prefix and that it =20
won't use both types in a single context? this may make sense, but i am =20=

not sure we want to hardcode this as the default behaviour...

>
> 13 and 16: may want to say that this only applies in the case of MIPv6
>

ok

> 14 and 15: see earlier
>

i guess i have addressed this earlier...

> 17: may want to make this one of the first rules after making sure =20
> there is reachability.  :-)
>

this is when you need to select a locator pair after a failure, i guess =20=

so this rule would result in returning to the ulid pair once that the =20=

alternative locator pair that is being used fails... but we can remove =20=

this one...

> What about making sure we only use source addresses that we know the =20=

> correspondent knows we have, and/or are covered by HBA?
>

or cga...

but this verification is needed in order to be part of Ls(peer), =20
according to the shim prtocol, but we can include a comment about this =20=

in the security considerations section...

> Security considerations: may want to think about the situation where a =
=20
> host uses temporary addresses, whether or not it lets the other side =20=

> know about its non-temporary addresses.
>

indeed comments about temp address should be included in the sec cons =20=

section

thanks,marcelo

> Iljitsch
>

Delivery-date: Wed, 28 Jun 2006 09:40:56 +0000
Date: Wed, 28 Jun 2006 12:40:04 +0300
From: Jari Arkko <[email-masked]>
To: Sam Xia <[email-masked]>
CC: 'shim6-wg' <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Sam Xia wrote:

>Yes, I agree. The actual value for these timers should be tested in the real
>experimentation. And they should be tuned according to experimentation
>result. 
>Anyway, to add more texts describing how to determine the value is good. For
>example, there is a keepalive option for TCP connection; the draft should
>address
>how these timer value imposes TCP connection. And the interactions between
>these timers and other tranportation layer protocols should be studied
>further.
>  
>
I can add something about the values requiring further
experimentation, and that they have a relationship to what transport
protocols are doing.

--Jari

Delivery-date: Wed, 28 Jun 2006 01:42:00 +0000
Date: Wed, 28 Jun 2006 09:40:55 +0800
From: Sam Xia <[email-masked]>
Subject: RE: review of draft-ietf-shim6-failure-detection-03.txt
To: 'Jari Arkko' <[email-masked]>
Cc: 'Iljitsch van Beijnum' <[email-masked]>, 'shim6-wg' <[email-masked]>

Hi, Jari,
   some further discussion inline:

 Best Regards, Sam Xia 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Monday, June 26, 2006 6:13 PM
> To: Sam Xia
> Cc: 'Iljitsch van Beijnum'; 'shim6-wg'
> Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
> 
> Hi Sam,
> 
> And thanks your comments! Some further discussion inline:
> 
> >    As for section 6.4 (behaviour), maybe it is a better 
> specification 
> >form to seperate the text explaination and move them to the 
> >corresponding the state machine section. Then reader can easily 
> >understand what the draft says.
> >  
> >
> I have merged the description and the state machine in version -05.
> Lets see if you like it better.
> 
> >   And why do you think it is suitable to define the value for send 
> >timer and alive timer as 10s and 3s?
> >  
> >
> The first of these reflects the timeframe under which Shim6 
> attempts to recover from a perceived problem. It can not be 
> too long (e.g. minutes) because otherwise recovery would not 
> be useful for existing sessions.
> But it can not be too short either, because temporary 
> glitches would cause unnecessary Shim6 activity.
> 
> The second timer reflects the need to send keepalive messages 
> under a specific situation (one-way traffic) such that we get 
> feedback on whether recovery should be started on not.
> 
> Its clear that experimentation with suitable values will be 
> needed, as well as dynamic adjustments. But we've tried to 
> avoid specifying too many mechanisms for now, until we get 
> implementation and deployment experience.

Yes, I agree. The actual value for these timers should be tested in the real
experimentation. And they should be tuned according to experimentation
result. 
Anyway, to add more texts describing how to determine the value is good. For
example, there is a keepalive option for TCP connection; the draft should
address
how these timer value imposes TCP connection. And the interactions between
these timers and other tranportation layer protocols should be studied
further.

> 
> >  In my opinion, introduction of shim6 to ipv6 has add the 
> complexity 
> >of ip layer very much; and shim6-failure-detection is not simple. I 
> >don't know what is the last performance.
> >  
> >
> It does add complexity, yes. The questions though are if (a) 
> this complexity is a smaller price to pay than the pain from 
> having no multihoming or the complexity from other, 
> alternative solutions, and (b) whether there is something 
> that we could do to reduce complexity.
> 
> On point b, I'm not sure there is a lot we can do. At least 
> not without revisiting some of the requirement decisions, 
> such as the need to support at least some scenarios where 
> there's only unidirectional connectivity.
> 
> Thoughts?
> 
> --Jari
> 
> 
> 

Delivery-date: Tue, 27 Jun 2006 10:22:32 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: draft-ietf-shim6-locator-pair-selection-00.txt
Date: Tue, 27 Jun 2006 12:21:26 +0200

Hi Marcelo,

Apparently your visit to the Nomadiclab was a productive one, judging  
by the ackowledgment sections of all those drafts.  (-:

Note that this draft overlaps to a large degree with http:// 
www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt  
(STILL not posted by the secretariat 8 days after the fact...)

I found some of the text a bit hard to follow, but it's hard to  
pinpoint exact problems, except maybe that you use weight and weight*  
as different variables, which I don't like. How are you going to  
pronounce the second one?? Also, just before section 2.2 the text  
ends and without introduction, there is a formula. It is not  
immediately obvious that this formula means the same thing as the  
preceding paragraph. Words to this effect or even letting the  
paragraph end in a colon rather than a period would help.

I don't think using LOLs(peer) is a good choice, because this assumes  
that we always know what the LOLs for the peer are, without regard to  
the process of communicating the set back and forth or the  
possibility that a peer may not disclose all of its LOLs. Another  
name for this would be better.

I'm not sure if reachable/unknown/unreachable is expressive enough,  
maybe it's better to express this as a more gliding scale. I'm not  
sure yet, though.

I see you copied the weight calculation from the SRV RFC. Wouldn't it  
be easier just to say what the results should be and refer to this  
RFC for an example?

I'm slightly worried about using so many random numbers, is there  
anyone who knows how hard those are to generate?

I was slightlty shocked when I saw you have 17 rules. I think this is  
way too many, hopefully this can be reduced. One way to do this would  
be to translate as many decisions as possible into a numbers or bit  
mapped flags which can be compared much more easily. Don't forget  
that math can easily be pipelined and parallelized in a modern CPU  
while if/thens can be detrimental to performance and make software  
harder to debug. Example of what I mean:

preference = priority * 4096 + scope * 256 + weight * random[0-255]

Maybe even divide by the number of seconds since the last successful  
packet exchange...

Scope can also be done as global = 1, site = 2, link local = 4, ipv4  
= 8 then do a binary AND for source/dest and if the result != 0 the  
scopes are compatible, if == 0, these addresses don't make for a  
working pair.

Now let's have a look at those 17 rules...

1: src == dst??? Either this is a mistake and you mean something like  
src1 == src2 or I seriously don't get it

3: isn't this covered by the notion of being locally operational?

5: may overrule priority information, I think we want this in some  
way but this is probably too simple (note that I talk about stopping  
address pair exploration for addresses / pairs with equal or lower  
preference but continue for ones with higher preference)

6 and 7: shouldn't addresses of different families or scope be  
procluded from pairing up in the first place? (Although there are  
some corner cases where different scopes may work.)

8: mentions locator pair table, but this isn't defined in the draft,  
probably needs a reference

9: this is unnecessary.

10 and 11: it's becoming unclear to me how this list works. In BGP  
you enter with a list of items and continue with the ones that "win"  
a rule until you're left with one and that's the best one so you  
choose that one. Another way to approach such a list is "if (r1 &&  
r2 ... r16 && r17) then use this pair" where the pairs are pre-sorted  
for preference, but you seem to mix the two approaches here.

12: I think this is inappropriate here. Yes, there should be a way to  
prefer temporary addresses, but this is a policy setting on most  
systems so it shouldn't be hardcoded into shim6 or something related  
to shim6. A better way to handle this would be to take temporary yes/ 
no into consideration when building the LOL. Note that generally, a  
host will have a temporary and a regular address in the same prefix.  
The two of those would be equivalent for the purposes of shim6 so  
there's no need to include both.

13 and 16: may want to say that this only applies in the case of MIPv6

14 and 15: see earlier

17: may want to make this one of the first rules after making sure  
there is reachability.  :-)

What about making sure we only use source addresses that we know the  
correspondent knows we have, and/or are covered by HBA?

Security considerations: may want to think about the situation where  
a host uses temporary addresses, whether or not it lets the other  
side know about its non-temporary addresses.

Iljitsch

Delivery-date: Tue, 27 Jun 2006 08:22:51 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt 
Date: Tue, 27 Jun 2006 11:22:41 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 27/06/2006, a las 11:05, Iljitsch van Beijnum escribi=F3:

> On 22-jun-2006, at 17:14, marcelo bagnulo braun wrote:
>
>> first of all, the possibility of using the flow label is not=20
>> considered, why is that?
>
> I know that we had long discussions about this but I can't seem to=20
> remember what's useful about using the flowlabel...
>

well, the benefit is that you don't have the overhead of the extension=20=

header and you don't rely on specific ulp

the drawbacks are that you need the shim bit int he v6 header (i.e. new=20=

next header values for common protocols and that you are imposing (a=20
few) constraints on future usages of the flow label field for shimmed=20
packets)

we have included a summary of the discussion in Appendix D.2 of the=20
shim protocol draft which i think describes pretty much how a solution=20=

based on the flow label could be done. i guess this could be a starting=20=

point

>> I think it is a good option and it is much cleaner than using the=20
>> tcp/UDP ports... i would suggest to include it.
>
> I'll dredge up ealier discussions.
>
>> Second, i am not sure if using transport ports is the best option=20
>> since it would limit the context to a single communication... or are=20=

>> you considering binding multiple port pairs to the same shim=20
>> context?... in any case, i guess we would need to flesh out this a=20
>> bit more in order to understand how would it work...
>
> I agree that this isn't necessarily the best way to do it, but if a=20
> receiver says it can demultiplex on port numbers, why not take=20
> advantage of that?

because of complexity... special cases introduce additional complexity,=20=

since you need to deal with TCP, UDP, IPSec, and so on

I would rather have a solution that are general, like the flow label=20
one.

besides, as i pointed earlier you would need to associated a context to=20=

each transport connection, right?

>
> I'll look at the multiple sessions per context issue.
>
>> Another possibility would be to use IPSec SPI field, a la hip, in=20
>> case that the communication is using IPSec
>
> Yes, this could be useful.
>
>>> When bit 0 is set, the host indicates that it knows how to=20
>>> demultiplex
>>> packets belonging to the shim context being negotiated under all
>>> circumstances, so the sender MUST NOT add a shim header to these
>>> packets.
>
>>> However, in most cases (as outlined earlier) the cooperation of the
>>> sender is required to make sure that multiplexing can be done
>>> successfully, so when bit 0 is set to zero, the shim6 header may=20
>>> only be
>>> suppressed when the hosts involved have at least one capability in
>>> common. If there is any doubt, the shim6 header MUST NOT be=20
>>> suppressed.
>
>> i fail to understand this part...
>
>> i mean when bit 0 is set, the peer must or must not suppress the=20
>> header?
>
> Each bit indicates a capability that may or may not apply in a given=20=

> situation. For instance, if the bit for transport demultiplexing is=20
> set, but there is a session from A1 to B1 and from A2 to B1 where both=20=

> sessions use the same port number, it won't be possible to demultiplex=20=

> on transport information alone. So in order to be able to suppress the=20=

> header, the sender and receiver must have set the same bit, and the=20
> sender must know that the state between the hosts conforms to the=20
> limitations of the demultiplexing strategy that is indicated by the=20
> bit in question. Only if that's the case, the sender may suppress the=20=

> header.
>
> Bit 0 is a special case, because there are no limitations: if this bit=20=

> is set, the header MUST always be suppressed.
>

yes i think i understand that, but then it is stated that in case of=20
doubt the shim6 header must not be suppressed (even if bit 0 is set)=20
This is what i find confusing.... I guess that what it should be stated=20=

is that if the peers are not sure they can suppress the header, the=20
must not set bit 0

Regards, marcelo

> Iljitsch
>

Delivery-date: Tue, 27 Jun 2006 08:07:13 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt 
Date: Tue, 27 Jun 2006 10:05:58 +0200
To: marcelo bagnulo braun <[email-masked]>

On 22-jun-2006, at 17:14, marcelo bagnulo braun wrote:

> first of all, the possibility of using the flow label is not  
> considered, why is that?

I know that we had long discussions about this but I can't seem to  
remember what's useful about using the flowlabel...

> I think it is a good option and it is much cleaner than using the  
> tcp/UDP ports... i would suggest to include it.

I'll dredge up ealier discussions.

> Second, i am not sure if using transport ports is the best option  
> since it would limit the context to a single communication... or  
> are you considering binding multiple port pairs to the same shim  
> context?... in any case, i guess we would need to flesh out this a  
> bit more in order to understand how would it work...

I agree that this isn't necessarily the best way to do it, but if a  
receiver says it can demultiplex on port numbers, why not take  
advantage of that?

I'll look at the multiple sessions per context issue.

> Another possibility would be to use IPSec SPI field, a la hip, in  
> case that the communication is using IPSec

Yes, this could be useful.

>> When bit 0 is set, the host indicates that it knows how to  
>> demultiplex
>> packets belonging to the shim context being negotiated under all
>> circumstances, so the sender MUST NOT add a shim header to these
>> packets.

>> However, in most cases (as outlined earlier) the cooperation of the
>> sender is required to make sure that multiplexing can be done
>> successfully, so when bit 0 is set to zero, the shim6 header may  
>> only be
>> suppressed when the hosts involved have at least one capability in
>> common. If there is any doubt, the shim6 header MUST NOT be  
>> suppressed.

> i fail to understand this part...

> i mean when bit 0 is set, the peer must or must not suppress the  
> header?

Each bit indicates a capability that may or may not apply in a given  
situation. For instance, if the bit for transport demultiplexing is  
set, but there is a session from A1 to B1 and from A2 to B1 where  
both sessions use the same port number, it won't be possible to  
demultiplex on transport information alone. So in order to be able to  
suppress the header, the sender and receiver must have set the same  
bit, and the sender must know that the state between the hosts  
conforms to the limitations of the demultiplexing strategy that is  
indicated by the bit in question. Only if that's the case, the sender  
may suppress the header.

Bit 0 is a special case, because there are no limitations: if this  
bit is set, the header MUST always be suppressed.

Iljitsch

Delivery-date: Mon, 26 Jun 2006 18:52:30 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: reachability also for non-shim protocols
Date: Mon, 26 Jun 2006 20:51:49 +0200

I've been thinking a bit more about the issues with making the  
reachability detection protocol more general so it can be used for  
protocols other than shim6 as well. I'll be calling shim6 and other  
protocols that are interested in reachability "client protocols".

The whole process of rehoming to a new address pair can be broken up  
in several parts:

1. Make a list of individual addresses / address pair under  
consideration ordered by preference

2. Order available address pairs by likelihood of being reachable

3. Integrate 1 and 2 into a single ordered lists of address pairs  
(order of subsequent probing)

4. Schedule probes, considering exponential backoff

5. When packets are received, update 2

6. Choose an address pair and perform a return routability check

Step 1 must be done by the client protocol, and if it supports  
preferences, those will probably be per session rather than the same  
for all sessions.

For step 2 there is no client protocol specific information so it can  
be done host-wide. It's also very useful to include information from  
other sessions, contexts and client protocols, including upper layer  
feedback. For instance, if a host has two addresses and a dozen of  
sessions tied to each, and suddenly there are problems with stuff  
tied to address 1 but not address 2, it makes sense to avoid pairs  
with source address 1.

It doesn't matter too much how 3, 4  and 5 happen, although ideally,  
scheduling happens host-wide so synchronization and temporary  
congestion are avoided.

6 is again something that must happen in the client protocol. In  
theory, making sure the other side is who we think it is can be done  
for more than one client protocol at the same time (this is what I  
tried to accomplish in http://www.muada.com/drafts/draft-van-beijnum- 
shim6-reach-detect-00.txt which the secretariat still hasn't  
posted...) but in practice that is the firewall problem, which can  
make it such that a certain path is usable for one client protocol,  
but not for another, because the second one is filtered out by a  
firewall.

So the return routability check must be performed by each client  
protocol itself. Considering all the ways in which this can go wrong,  
performing the return routability checks involves most of the  
complexity of probing reachability in the first place, so we must  
invoke the end-to-end principle which I think applies in the  
following way: if all cient protocols must do all this work  
themselves anyway, having another instance of the same mechanism in  
the middle serves no purpose.

However, there is synergy to be had and congestion to be avoided by  
sharing the reachability detected by other protocols as hints. The  
trikcy part is figuring out how this should happen. I want to say  
"API" but how many APIs can we stand to have? And because all/most of  
this happens in the kernel, it should be possible for implementers to  
do the right thing without any guidance from us. Or maybe not. I  
don't know.

It would be worthwhile to separate the specification into a shim- 
specific and non-shim-specific part to promote code reuse, though.

Thoughts?

Delivery-date: Mon, 26 Jun 2006 13:26:06 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Mon, 26 Jun 2006 15:25:06 +0200
To: Jari Arkko <[email-masked]>

On 26-jun-2006, at 13:54, Jari Arkko wrote:

> One of the reason why I think generality is something that we
> need to leave for future verification is that other contexts like
> HIP have significantly more complex requirements than Shim6.
> In particular, HIP needs to work with IPv4 and NATs.

One way to address this is to split the reachability detection into a  
shim-specific part (the keepalives) and a generic part (the path  
exploration), so that the generic part can evolve independent of shim6.

Note that I'm not saying this is necessarily the path we should take,  
but seeing that there is other stuff that can also benefit from  
reachability detection, it certainly seems prudent to think about  
this now while we still have the opportunity to easily go into  
another direction.

> I am uncertain if the ICMP mechanism for the path exploration
> part is the best way forward. The entire REAP protocol could
> certainly be encapsulated in any "user" protocol.

Yes, but that way it's hard to avoid it from being implemented more  
than once and it's impossible to keep it from running more than once.

> But many
> scenarios that I can see do not necessarily work well with ICMP,
> particularly with one version of ICMP. In MOBIKE, for instance,
> it would have been inappropriate to use anything else than the
> regular NAT-T UDP at the bottom, because only that can show
> whether actual MOBIKE/IKEv2/IPsec traffic will get through. And
> what about HIP running over IPv4?

Since we're determining unidirectional reachability, NAT is not  
actually as big a problem as it would ordinarily seem. The big issue  
with NAT is making sure that both ends know the addresses on both  
sides and there are translation rules that allow incoming packets to  
be delivered. But you're right ICMP won't work with NAT, we'd have to  
use UDP for that. But I guess it would make sense to develop a non- 
NAT IPv6 version first and then see what needs to be done to make it  
work over IPv4 with NAT.

> But as a general rule, I'd like to
> get a working, as simple as possible Shim6 mechanism out there.
> Even if its not optimized for all situations. We can work on  
> extensions
> like fate sharing between contexts later, too.

I disagree with that approach, I think we should make the first  
version as good as it can be. I don't see much added value in  
finishing this work a little earlier, we're obviously too late to  
avoid PI in IPv6 now (if that can be avoided it won't be because of  
shim6) or avoid having legacy non-shim IPv6 implementations out  
there, but at the same time IPv6 isn't deployed on any measurable  
scale yet so there is still (some) time.

> Was there other issues related to probe storms? We do have
> exponential back-off.

Not really. There is no description of how this works.

>> Another thing that's missing completely from this draft is a
>> discussion of how to use address pair preference information. This
>> makes it impossible to address traffic engineering needs.

> This is important, but can be addressed separately.

No, that would make it MUCH harder, as this will only work well if  
both ends implement it. And we're getting flack for not paying  
attention to traffic engineering as it is.

>> This doesn't say what shim6 implementers should do. In my opinion:
>> keep using deprecated addresses as the ULID/primary locator as long
>> as possible, but prefer non-deprecated addresses when selecting
>> alternative locators.

> Right. But I actually already deleted Section 4.5 and the discussion
> of deprecated addresses. IPv6 specifications already call for use
> of non-deprecated addresses for new communications, and disallow
> the use of invalid addresses. So its not clear that we need to say  
> more.

Leaving out all mention of deprecated addresses is ok by me, but as  
soon as you bring it up it's a good idea to say what you want to  
happen with them.

>> Data packets as opposed to what other types of packets?

> I added a clarification. Basically, its all packets including both
> ULP packets and SHIM6 control messages, but NOT keepalives
> or probes.

I think it's a good idea to consider TCP ACKs with no user data as  
non-data packets that don't need to generate return traffic as well.

>> So when we receive a keepalive from the other side, _we_ stop sending
>> keepalives? This may be the right thing to do, but it's not obvious
>> to me why. Some explanation would help.

> Keepalives are only used if there's one-way communication. Since the
> other side sends a keepalive, its not sending anything else at that
> time. Hence we have no need for keepalives.

But do we need this rule? It may make implementations more complex  
without any benefit.

>> The keepalives are sent at an interval of 3 seconds (or shorter, I
>> imagine that an implementation isn't going to keep an exact timer for
>> each context, any rounding must obviously be in the down direction)
>> and the timeout is 10 seconds. In these 10 seconds you'd normally
>> receive 3 keepalives, while 1 is enough to indicate that the other
>> side is still alive. The other 2 are only there in case of packet
>> loss. I think that's excessive. Starting the full reachability
>> exploration because of incidental packet loss isn't such a big deal
>> that it warrants sending three times as many packets as necessary.

> The question is what the right number is. We want to avoid
> entering exploration needlessly, so I'd rule 1 keepalive out.
> We now have 3, are you arguing for 2? I'd be fine with that,
> but I note that we don't have a lot of evidence to support
> either view. We're going to have to revisit this after we get
> the experience.

Why not leave it up to the implementers? If we say that after 10  
seconds the full path exploration starts, implementers are free to  
experiment with what works well (3, 4, 8 seconds between keepalives)  
without any need to revisit the spec.

>> Why would a keepalive need an id field?

> So that a probe reception report can indicate
> seeing a recent keepalive.

I see. But what about the case where there are no keepalives, only  
data packets? In that case, there's no id field either.

>> I believe that since the id of the last received probe is included,
>> the iseeyou flag is unnecessary.

> But we also have the case where you report seeing data packets but
> no probes.

Good point. But couldn't that be solved by using a special value for  
the last seen id?

> But if you have ideas on how this could be simplified -- perhaps by
> not thinking about the data packets during exploration -- those
> would be welcome.

Way ahead of you - I wasn't thinking about data packets during  
exploration until now.  :-)

>> Although copying back the last seen id seems to do the job, I can't
>> help but feel that it would be preferable to add timers to reach
>> round trip times and copy back more received ids and also sent ids.
>> This allows the receiver of a probe to determine which of the probes
>> that made it to the other side did so faster, so it can select the
>> address pair with the shortest round trip time.

> Right. But all that can go into extensions. I'd like to have the
> minimum necessary to get this spec done.

Let's split the difference and specify the fields, but make (most of)  
their use optional.

I severely dislike having fixed length data in TLV format, because  
that makes parsing much harder. If you look at Van Jacobson's work  
with TCP you'll see that a fixed header allows extremely streamlined  
implementations.

>> Including sent ids along with the addresses the probe with that id
>> was sent to helps the receiver determine that some probes didn't make
>> it (yet). If a probe didn't work in one direction of an address pair,
>> it's reasonable to assume that it may also not work in the other
>> direction and try other pairs first.

> True as well, but again perhaps material for future
> optimizations.

I really like having multiple ids for earlier probes in there, it  
should cut down on the number of packets exchanged, and I also  
suspect that there could be race conditions when certain packets are  
lost and not others so that an implementation that only echos the  
last seen id may stay in an oscillating state, but I haven't been  
able to think of an example so far.

Delivery-date: Mon, 26 Jun 2006 13:26:05 +0000
Date: Mon, 26 Jun 2006 16:25:36 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Continuing my response... unfortunately
what we find below is not in the -05 that
was submitted in before the deadline. Inline:

> I believe the next example (the fifth, I think?) is flawed because A 
> doesn't send anything after it has sent a data packet, even though it 
> never receives a return packet. The same is true for the example 
> after that.

You are correct. The examples have been fixed in -06.

> When does address pair exploration conclude, both in the cases where 
> there is alternative reachability, and in the case when there appears 
> to be no reachability at all? The exponential backoff isn't described.

The exponential backoff description was added to -05.
The draft still states that exploration does not conclude; its
allowed to keep on sending probes at a very low rate.

I think its easier to deal with the termination using garbage
collection than by some other means.

> The keepalive is a fairly long packet. I think just a shim header as 
> would be used for data packets but with no ULP following the shim 
> header would be sufficient.

>From what I can see, we add 20 bytes on top of the IPv6 header. This
could be reduced, of course, but I'm currently unconvinced that
we need to worry about this optimization. Keepalives are only sent
when you have one-way communication. In any case any reduction
could not exceed 33%, given size of the IP header.

> Requiring random numbers in packets that are sent rather frequently 
> is a bad idea, because it depletes the typically limited amount of 
> entropy that's available for strong random number generation rather 
> quickly and semi-random number generation may be somewhat expensive 
> (and not that good). And I don't see what good an id does in a 
> keepalive anyway... Also, there may be reasons to have non-random 
> numbers, such as ease of lookup.

Well, we could remove the payload/keepalive reporting from the protocol.
It would in some cases need a few more messages, but it would likely
be simpler, and take a few bytes out of frequently needed messages.
Do others have an opinion here?

> The description of the different messages repeats text that is the 
> same for different messages, which is very tedious and makes it 
> likely that people will miss the things that are actually different. 
> (That's why programmer's keyboards don't have ctrl-c/ctrl-v keys: 
> reuse code, don't copy it.)

Fixed. More reduction may come if we remove identifiers from
keepalives, and simplify the option structure.

> The use of options for mandatory fields is awkward.

I agree. This is initially part of the generality design, but
its painful to keep it around. I'd be happy to move things
back into the messages, unless its something that appears
multiple times like a reception report.

> "   The node maintains also the Send and Keepalive timers."
>
> These timers were previously unnamed, it would be better to use their 
> names as soon as they're introduced.

Fixed.

>
> "   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.  If the node is in the Exploring
>    state it transitions to the ExploringOK state, sends a Probe message
>    with the I See You flag set to 1 (Yes), and starts the Send timer.
>    In the ExploringOK state the node stops the Send timer if it was
>    running, but does not do anything else."
>
> I don't have a good feeling about this... It's too hard to determine 
> what should be happening. Maybe it would be better rather than go 
> down the list of packets that are sent/received and describe the 
> behavior in each state, to take one state at a time and describe what 
> happens with packets in that state.

I believe this detailed list of packets vs. each state is in the draft
(in the informational part). Its now intermixed with the explanation,
so it may be easier to read.

Or are you questioning the wiseness of taking an action
based on the reception of a payload packet? We could also
define the protocol solely based on the signaling packets.
But with data packets it may potentially converge faster, after
a transient failure, for instance.

>    Upon a timeout on the Keepalive timer the node sends a Keepalive
>    message.  This can only happen in the Operational state.
>
> Why?

Because the timer is otherwise not running. Therefore,
it can't fire in other states.

> Why are there different Exploring and ExploringOK states? In both 
> cases, the host needs to continue trying different addresses, it's 
> mostly/only the other side that needs to behave differently when 
> there is successful reachability from them to us but not (yet) from 
> us to them.

Good question. The current description requires running the
Send timer in the ExploringOK state, but frankly I'm unsure
why this was put there, it doesn't seem to be required. And
the termination of the exploration really happens based
on the peer's event reports referring to your event reports.

The main difference right now is that retransmission use
iseeyou=yes vs. iseeyou=no in the different states. This
could perhaps be modelled in other ways too.

>    Garbage collection of SHIM6 contexts terminates contexts that are
>    either unused or have failed due to the inability of the exploration
>    process to find a working pair.
>
> How is the latter determined?
>
> This is an important issue. For instance, once that a shim context is 
> rehomed, will it ever return to using the primary locators?

I think the text is wrong. We can't really determine the inability
in any reasonable way, as the situation may change so that even
if we have tried all pairs, trying again may find that the path works
again.

I have changed this text to say that the garbage collection works
solely based on usage and age.

>    In the PDF version of this specification, an informational drawing
>    illustrates the state machine.  Where the text and the drawing
>    differ, the text takes precedence.
>
> I'm not reviewing the PDF state machine here as the text is normative.
>
>    A tabular representation of the state machine is shown below.  Like
>    the drawing, this representation is only informational.
>
> Then I'm ignoring this too.
>
> But I would be happier if they'd be removed, because either they're 
> superfluous as they're not normative, or they're actually necessary 
> to understand the protocol, which is even worse because they're not 
> part of the normative text.

The tabular representation has been very useful for me when trying
to ensure that we have covered all combinations of states and
events. And when I program, I like to take a state machine from
a spec and work based on that, but YMMV.

The picture OTOH is something that people may find it easier
to start with.

--Jari

Delivery-date: Mon, 26 Jun 2006 12:00:28 +0000
Date: Mon, 26 Jun 2006 15:00:19 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

A revision -05 that addresses Sam's and some of Iljitsch's
comments has been sent to the secretariat. Until it appears
it can be accessed here:

  http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-05.txt
  http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-05.pdf
  http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-05diff.html

--Jari

Delivery-date: Mon, 26 Jun 2006 11:55:31 +0000
Date: Mon, 26 Jun 2006 14:54:43 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Hi Iljitsch,

and thanks a lot for your very detailed comments! Further discussion
inline:

> Ok. First of all, have a look at my message from october 24th, some 
> comments are still valid.

Ok. Will follow-up.

> This draft works per-context exclusively. So if there are 2, 5 or 10 
> contexts between two hosts, this means 2, 5 or 10 times the amount of 
> work is done.
>
> I think it makes sense to see whether the mechanism can be made to be 
> more general, so that it can be used for other applications as well, 
> ranging from MIP (as indicated in the applicability draft) to tunnel 
> maintenance and maybe even peer-to-peer applications. However, it's 
> important that there is fate sharing between the reachability 
> protocol and the user protocol (shim in our case). I think this can 
> be solved by having the quick reachability verification stuff (= FBD) 
> encapsulated in the user protocol, but let the full path exploration 
> be a protocol of its own or live under ICMPv6 or some such. However, 
> this introduces some issues with knowing whether the same 
> correspondent lives at different addresses.

We have tried to keep the design general, but at the same time
the text in most recent versions talks only about Shim6. I'm not
sure I want to promise anything about the generality, or hold up
Shim6 because we have not figured out if the generality is there
or not.

One of the reason why I think generality is something that we
need to leave for future verification is that other contexts like
HIP have significantly more complex requirements than Shim6.
In particular, HIP needs to work with IPv4 and NATs.

I am uncertain if the ICMP mechanism for the path exploration
part is the best way forward. The entire REAP protocol could
certainly be encapsulated in any "user" protocol. But many
scenarios that I can see do not necessarily work well with ICMP,
particularly with one version of ICMP. In MOBIKE, for instance,
it would have been inappropriate to use anything else than the
regular NAT-T UDP at the bottom, because only that can show
whether actual MOBIKE/IKEv2/IPsec traffic will get through. And
what about HIP running over IPv4?

I am very sympathetic to making this general, and attempts trying
to use this for other purposes. Perhaps the ICMPv6 approach is
the right way forward. All I'm saying is that its less easy than it
may appear to be, and hence I do not want to hold up Shim6 work
by attempting to solve this issue now.

> In any event, I think just ignoring the possibility that there are 
> multiple contexts between two hosts isn't good enough. The issue of 
> avoiding "reachability probe storms" is somewhat related to this, and 
> also not addressed in the draft.

My recollection of the multiple contexts discussion is vague, but
note the issues that Marcelo pointed out. I agree that there's
a potential for more messages. But as a general rule, I'd like to
get a working, as simple as possible Shim6 mechanism out there.
Even if its not optimized for all situations. We can work on extensions
like fate sharing between contexts later, too.

Was there other issues related to probe storms? We do have
exponential back-off. I understand even with that, we're still
vulnerable to multiple packets from the same host, if there
are many contexts, and to multiple packets from a set of hosts,
if all hosts in the network experience the same probl�ms.

If there's some specific thing that we could do to address
these, I'd be happy to incorporate it to the draft.

> Another thing that's missing completely from this draft is a 
> discussion of how to use address pair preference information. This 
> makes it impossible to address traffic engineering needs.

This is important, but can be addressed separately.

> I believe section 3 (related work) is at best unnecessary and may 
> even confuse the reader.

I decided to take that section out entirely.

> The same is true of much of section 4  (definitions). Implementers
> know which addresses are usable and which  aren't, at least for the
> most part, so covering this in such detail  is superfluous. Things
> like "Both types of operational pairs could be  discovered and
> monitored through the following mechanisms:" have no  place in a
> protocol specification document, in my opinion. These need  to specify
> what IS, not what COULD be.

I think it is necessary to talk about our notion of usable addresses.

But you are right that the specification should be tighter than it
currently is. Take look at -05 when I post it, and see if you like the
result. I have basically required the support for getting information
to SHIM6 from the underlying IPv6 mechanisms, and left any other
possible optimizations (like L2 connectivity info) as optional.

> I suggest tightening the use of words like "operational", "work", 
> "reachable". They're mostly used interchangably in the draft.

Done.

> 4.5.  Miscellaneous
>
>    Addresses can become deprecated [3].  When other operational
>    addresses exist, nodes generally wish to move their communications
>    away from the deprecated addresses.
>
>    Similarly, IPv6 source address selection [6] may guide the selection
>    of a particular source address - destination address pair.
>
> This doesn't say what shim6 implementers should do. In my opinion: 
> keep using deprecated addresses as the ULID/primary locator as long 
> as possible, but prefer non-deprecated addresses when selecting 
> alternative locators.

Right. But I actually already deleted Section 4.5 and the discussion
of deprecated addresses. IPv6 specifications already call for use
of non-deprecated addresses for new communications, and disallow
the use of invalid addresses. So its not clear that we need to say more.

>
> "A "path" is defined as" should probably be in the "definitions" 
> section.

I rewrote most of the text that involved the use of
the word "path"; it was used incorrectly most of the
time.

> "when link layer" -> when a link layer

Fixed.

>
>    1.  The base timing unit for this mechanism is named Keepalive
>        Timeout.  Until a negotiation mechanism to negotiate different
>        values for this timer becomes available, the value (3 seconds)
>        specified in Section 6.5 SHOULD be used.
>
> Sending a keepalive every 3 seconds? That's way too often, IMO.

Note that this is only if you have one-way traffic. But do you have
a suggested other value for the timer? We need to receive
a couple at least during a Send Timeout interval (10s), and the entire
process needs to last less time than it takes for ULPs to give up.

>
>    2.  Whenever outgoing data packets are generated
>
> Data packets as opposed to what other types of packets?

I added a clarification. Basically, its all packets including both
ULP packets and SHIM6 control messages, but NOT keepalives
or probes.

>    4.  The reception of a REAP keepalive packet leads to stopping the
>        timer associated with the return traffic from the peer.
>
> So when we receive a keepalive from the other side, _we_ stop sending 
> keepalives? This may be the right thing to do, but it's not obvious 
> to me why. Some explanation would help.

Keepalives are only used if there's one-way communication. Since the
other side sends a keepalive, its not sending anything else at that
time. Hence we have no need for keepalives.

>
> What if an attacker generates spurious keepalives in order to get us 
> to stop sending keepalives on our side?

Hmm... this is a potential concern. The attacker would have
to send one message every 10 s, and he'd be able to prevent
the node from sending its own keepalives. But this wouldn't
result in the breakage of the communications, the nodes
would just move to exploring state and quickly confirm that
they have connectivity.

Even applying IPsec does not help here, because IPsec runs
on top of the shim layer.

I have written something about this in the security considerations
section. Let me know if you want to do something more.

>    6.  Send Timeout seconds (10 s; see Section 6.5) after the
>        transmission of a data packet with no return traffic on this
>        context, a full reachability exploration is started.  This
>        timeout period is larger than the Keepalive Timeout to
>        accommodate for lost keepalives and regular variations in round
>        trip times.
>
> The keepalives are sent at an interval of 3 seconds (or shorter, I 
> imagine that an implementation isn't going to keep an exact timer for 
> each context, any rounding must obviously be in the down direction) 
> and the timeout is 10 seconds. In these 10 seconds you'd normally 
> receive 3 keepalives, while 1 is enough to indicate that the other 
> side is still alive. The other 2 are only there in case of packet 
> loss. I think that's excessive. Starting the full reachability 
> exploration because of incidental packet loss isn't such a big deal 
> that it warrants sending three times as many packets as necessary. 
> (Note that this assumes the worst case of a unidirectional transport 
> protocol which isn't exactly the common case.)

The question is what the right number is. We want to avoid
entering exploration needlessly, so I'd rule 1 keepalive out.
We now have 3, are you arguing for 2? I'd be fine with that,
but I note that we don't have a lot of evidence to support
either view. We're going to have to revisit this after we get
the experience.

Left the draft now as-is. Others may comment on what we
should do here.

> I find it jarring that section 5.5 immediately jumps to examples, 
> before the protocol is fleshed out.

Yes - but on the other hand we need an overview before
the bits are laid out to view... I did not change this yet, but
if you have a specific suggestion, I'd be happy to change the
draft.

> Although the examples are  referred by using a number, they aren't
> actually numbered.

Fixed.

>
> Why would a keepalive need an id field?

So that a probe reception report can indicate
seeing a recent keepalive.

>
> In the first long example B times out once, but then doesn't send 
> more probes until it sees return traffic from A. Why does B stop 
> sending probes?

It just happens to have a retransmission policy that
places the next probing to a time beyond the reception
of the first succesful message from A. At that point it
knows enough to not continue its own process. I added
something about this to the draft.

> I believe that since the id of the last received probe is included, 
> the iseeyou flag is unnecessary.

But we also have the case where you report seeing data packets but
no probes.

But if you have ideas on how this could be simplified -- perhaps by
not thinking about the data packets during exploration -- those
would be welcome.

> Although copying back the last seen id seems to do the job, I can't 
> help but feel that it would be preferable to add timers to reach 
> round trip times and copy back more received ids and also sent ids. 
> This allows the receiver of a probe to determine which of the probes 
> that made it to the other side did so faster, so it can select the 
> address pair with the shortest round trip time.

Right. But all that can go into extensions. I'd like to have the
minimum necessary to get this spec done.

> Including sent ids along with the addresses the probe with that id 
> was sent to helps the receiver determine that some probes didn't make 
> it (yet). If a probe didn't work in one direction of an address pair, 
> it's reasonable to assume that it may also not work in the other 
> direction and try other pairs first.

True as well, but again perhaps material for future
optimizations.

The rest of the comments I have to defer beyond the submission
deadline, unfortunately. Need to ship the draft now. I will respond
to the e-mail later, however.

--Jari

> I believe the next example (the fifth, I think?) is flawed because A 
> doesn't send anything after it has sent a data packet, even though it 
> never receives a return packet. The same is true for the example 
> after that.

> When does address pair exploration conclude, both in the cases where 
> there is alternative reachability, and in the case when there appears 
> to be no reachability at all? The exponential backoff isn't described.
>
> The keepalive is a fairly long packet. I think just a shim header as 
> would be used for data packets but with no ULP following the shim 
> header would be sufficient.
>
> Requiring random numbers in packets that are sent rather frequently 
> is a bad idea, because it depletes the typically limited amount of 
> entropy that's available for strong random number generation rather 
> quickly and semi-random number generation may be somewhat expensive 
> (and not that good). And I don't see what good an id does in a 
> keepalive anyway... Also, there may be reasons to have non-random 
> numbers, such as ease of lookup.
>
> The description of the different messages repeats text that is the 
> same for different messages, which is very tedious and makes it 
> likely that people will miss the things that are actually different. 
> (That's why programmer's keyboards don't have ctrl-c/ctrl-v keys: 
> reuse code, don't copy it.)
>
> The use of options for mandatory fields is awkward.
>
> "   The node maintains also the Send and Keepalive timers."
>
> These timers were previously unnamed, it would be better to use their 
> names as soon as they're introduced.
>
> "   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.  If the node is in the Exploring
>    state it transitions to the ExploringOK state, sends a Probe message
>    with the I See You flag set to 1 (Yes), and starts the Send timer.
>    In the ExploringOK state the node stops the Send timer if it was
>    running, but does not do anything else."
>
> I don't have a good feeling about this... It's too hard to determine 
> what should be happening. Maybe it would be better rather than go 
> down the list of packets that are sent/received and describe the 
> behavior in each state, to take one state at a time and describe what 
> happens with packets in that state.
>
>    Upon a timeout on the Keepalive timer the node sends a Keepalive
>    message.  This can only happen in the Operational state.
>
> Why?
>
> Why are there different Exploring and ExploringOK states? In both 
> cases, the host needs to continue trying different addresses, it's 
> mostly/only the other side that needs to behave differently when 
> there is successful reachability from them to us but not (yet) from 
> us to them.
>
>    Garbage collection of SHIM6 contexts terminates contexts that are
>    either unused or have failed due to the inability of the exploration
>    process to find a working pair.
>
> How is the latter determined?
>
> This is an important issue. For instance, once that a shim context is 
> rehomed, will it ever return to using the primary locators?
>
>    In the PDF version of this specification, an informational drawing
>    illustrates the state machine.  Where the text and the drawing
>    differ, the text takes precedence.
>
> I'm not reviewing the PDF state machine here as the text is normative.
>
>    A tabular representation of the state machine is shown below.  Like
>    the drawing, this representation is only informational.
>
> Then I'm ignoring this too.
>
> But I would be happier if they'd be removed, because either they're 
> superfluous as they're not normative, or they're actually necessary 
> to understand the protocol, which is even worse because they're not 
> part of the normative text.
>
>

Delivery-date: Mon, 26 Jun 2006 10:14:19 +0000
Date: Mon, 26 Jun 2006 13:13:09 +0300
From: Jari Arkko <[email-masked]>
To: Sam Xia <[email-masked]>
CC: 'Iljitsch van Beijnum' <[email-masked]>,  'shim6-wg' <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Hi Sam,

And thanks your comments! Some further discussion inline:

>    As for section 6.4 (behaviour), maybe it is a better specification form
>to seperate the text explaination and move them to the corresponding the
>state machine section. Then reader can easily understand what the draft
>says.
>  
>
I have merged the description and the state machine in version -05.
Lets see if you like it better.

>   And why do you think it is suitable to define the value for send timer
>and alive timer as 10s and 3s?
>  
>
The first of these reflects the timeframe under which Shim6 attempts
to recover from a perceived problem. It can not be too long (e.g. minutes)
because otherwise recovery would not be useful for existing sessions.
But it can not be too short either, because temporary glitches would
cause unnecessary Shim6 activity.

The second timer reflects the need to send keepalive messages
under a specific situation (one-way traffic) such that we get
feedback on whether recovery should be started on not.

Its clear that experimentation with suitable values will be
needed, as well as dynamic adjustments. But we've tried to
avoid specifying too many mechanisms for now, until we
get implementation and deployment experience.

>  In my opinion, introduction of shim6 to ipv6 has add the complexity of ip
>layer very much; and shim6-failure-detection is not simple. I don't know
>what is the last performance.
>  
>
It does add complexity, yes. The questions though are if (a) this
complexity is a smaller price to pay than the pain from having no
multihoming or the complexity from other, alternative solutions,
and (b) whether there is something that we could do to reduce
complexity.

On point b, I'm not sure there is a lot we can do. At least not
without revisiting some of the requirement decisions, such
as the need to support at least some scenarios where there's
only unidirectional connectivity.

Thoughts?

--Jari

Delivery-date: Sat, 24 Jun 2006 11:00:57 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Sat, 24 Jun 2006 12:59:11 +0200
To: marcelo bagnulo braun <[email-masked]>

On 22-jun-2006, at 16:59, marcelo bagnulo braun wrote:

>> This draft works per-context exclusively. So if there are 2, 5 or  
>> 10 contexts between two hosts, this means 2, 5 or 10 times the  
>> amount of work is done.

> i agree that this would be a nice feature. the problem with this is  
> how do you identify the peer in such a way that you can probe all  
> the existing contexts.

Have a look at the revision of my reachability detection draft:
http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt

Note that this is an update of draft-ietf-shim6-reach-detect-01.txt  
and it's not yet posted by the secretariat.

> The other option would be to use a single probe/keepalive for all  
> the contexts between two peers. In order to do that we need a mean  
> to identify the peer so that the receiver of the packet can  
> identify all the contexts corresponding to the same hosts and apply  
> the received packet to all the contexts.

Indeed.

> BAsically this would introduce the notion of endpoint in the shim  
> context/protocol (which is not present today), since today the  
> granularity is ulid pairs (as oposed to endpoint pairs)

Not necessarily, read my draft.

> this would be a considerable change in the protocol i guess, but  
> may be explored if people deem it relevant.

It makes the protocol a bit more complex, but it does allow it to be  
used by many different protocols at the same time.

> As a general comment, i am kind of worried about the complexity of  
> the resulting protocol, including shim protoc and the failure  
> detection protocol and i would really preffer to try to simplify  
> the protocol rather than making it more complex, even if this means  
> loosing some optimization for some cases.

I suppose the case where there are multiple contexts between two host  
won't be that common that it's worth too much effort to deal with it.  
But if other protocols also need this, then it would be MUCH better  
to have a single code base that's shared by all of them rather than  
have essentially the same thing pop up in different places.

> I am concerned about having a complex protocol that may become  
> error prone (we already have feedback expressing this concern BTW)

I hate complexity as much as the next IETFer, but leaving the last  
10% out just because it's simpler is generally not a good solution.

>>  However, it's important that there is fate sharing between the  
>> reachability protocol and the user protocol (shim in our case). I  
>> think this can be solved by having the quick reachability  
>> verification stuff (= FBD) encapsulated in the user protocol, but  
>> let the full path exploration be a protocol of its own or live  
>> under ICMPv6 or some such.

> not sure why do you think this is needed. Defining the protocol  
> messages in a way that they can be included in the shim6 header as  
> well as in the mobility header or the hip header would be good  
> enough to allow using the failure detection protocol in other  
> protocols.... what am i missing?

See the discussion above, and the need for fate sharing between the  
reachability protocol and the "user" protocol. If we want the  
reachability detection to be shared by different users, then it can  
happen that one protocol is filtered and another isn't. So we  
probably want the reachability detection to be independent of the  
"user" protocols and then when the reachability protocol says that  
something is reachable, the user protocol does a quick check using  
its own protocol number to be sure it actually works.

>> Another thing that's missing completely from this draft is a  
>> discussion of how to use address pair preference information. This  
>> makes it impossible to address traffic engineering needs.

> well, i have been working on this and i have submitted a draft  
> about how to perform locator pair selection, including reachability  
> information and also preference information from the shim protocol

> you can find it at:

> http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair- 
> selection-00.txt

> of course your feedback would be very welcome

I'll have a look at it.

> i think that the definition section is very useful, because the  
> insight it provides about the different states of an address and  
> address pairs are very important.

I agree, but my problem with the definition section is that it  
contains too much stuff that shouldn't be there. It's not unusual to  
have to go back to the definition section several times during  
reading, so a definition section needs to be as concise as possible.

>> I suggest tightening the use of words like "operational", "work",  
>> "reachable". They're mostly used interchangably in the draft.

> i don't think this is the case.
> i find this differences relevant imho

I'm not sure there is a difference, and if there is, what it is...

>> This doesn't say what shim6 implementers should do. In my opinion:  
>> keep using deprecated addresses as the ULID/primary locator as  
>> long as possible, but prefer non-deprecated addresses when  
>> selecting alternative locators.

> i think this should belong to the locator selection document...

Is that a separate document???

>>    2.  Whenever outgoing data packets are generated

>> Data packets as opposed to what other types of packets?

> signalling packets, such as keeplives or probes (is my understanding)

Sure, but the draft doesn't say that.

>>    4.  The reception of a REAP keepalive packet leads to stopping the
>>        timer associated with the return traffic from the peer.

>> So when we receive a keepalive from the other side, _we_ stop  
>> sending keepalives

> as i understand it, this means that we are not expecting another  
> packet (until we send a new packet, of course)

I guess. But shouldn't this follow from the general rules rather than  
be a specific one?

>> The keepalives are sent at an interval of 3 seconds (or shorter, I  
>> imagine that an implementation isn't going to keep an exact timer  
>> for each context, any rounding must obviously be in the down  
>> direction) and the timeout is 10 seconds. In these 10 seconds  
>> you'd normally receive 3 keepalives, while 1 is enough to indicate  
>> that the other side is still alive. The other 2 are only there in  
>> case of packet loss. I think that's excessive.

> would you suggest it to reduce it to 2 packets every 10 secs?

That's a bit better, but actually I think 1 in 10 seconds is enough,  
although that means you need to take a few extra seconds before you  
can time out. If you want to time out after 10 seconds then sending a  
keepalive after 8 would probably be a good choice.

> I mean, i think this protocol will require quite a lot of fine  
> tunning based on experience and simulations of the load... i guess  
> that what's in the current spec are resonable values for the time  
> being (i have no problem with changing them a bit, but as i said i  
> guess in depth fine tunning will be needed once we have more  
> experience...)

How is experience going to tell us anything that we don't know  
already in this case? If we go for one missed keepalive before a  
timeout that would be a new approach that may not work out well and  
then we can go back to 5 seconds or 3 seconds, but starting at 3  
means a lot of packets but as good as no unnecessary triggering of  
path exploration, there won't be any surprises there.

>> I believe that since the id of the last received probe is  
>> included, the iseeyou flag is unnecessary.

> you mean that if the id field is empty, this means iseeyou=no?

No, what I mean is that the value of this bit doesn't convey any  
interesting information.

Or maybe it really is a "reply requested" bit in disguise, like we  
discussed earlier.

>> Although copying back the last seen id seems to do the job, I  
>> can't help but feel that it would be preferable to add timers to  
>> reach round trip times and copy back more received ids and also  
>> sent ids. This allows the receiver of a probe to determine which  
>> of the probes that made it to the other side did so faster, so it  
>> can select the address pair with the shortest round trip time.

> i would suggest to leave this for future work, since it is added  
> complexity and it is not obvious to me that selecting the fastest  
> one is always the best choice.... (e.g. bandwidth is not considered)

I'd say: put in the fields, this is very little extra work, and the  
values can be ignored for simplicity when desired. Then, implementers  
can experiement with how they use them if they like.

>> The keepalive is a fairly long packet. I think just a shim header  
>> as would be used for data packets but with no ULP following the  
>> shim header would be sufficient.

> not sure what would you omit from the current packet format... i  
> mean, we need the context tag and the identifier and we need it to  
> make it extensible in the header....

No we don't. Data packets don't have these fields either and also  
indicate that the current context is working. Moreover: data packets  
that haven't been rewritten don't even have a shim header!

>> Requiring random numbers in packets that are sent rather  
>> frequently is a bad idea, because it depletes the typically  
>> limited amount of entropy that's available for strong random  
>> number generation rather quickly and semi-random number generation  
>> may be somewhat expensive (and not that good). And I don't see  
>> what good an id does in a keepalive anyway... Also, there may be  
>> reasons to have non-random numbers, such as ease of lookup.

> i guess this i neeeded to indeed verify that the reply was  
> generated as a response to the initial packet,

Keepalives are generated autonomously, not in response to other shim  
packets, so this is not relevant in this case.

>> I don't have a good feeling about this... It's too hard to  
>> determine what should be happening. Maybe it would be better  
>> rather than go down the list of packets that are sent/received and  
>> describe the behavior in each state, to take one state at a time  
>> and describe what happens with packets in that state.

> that would be the state machine i guess, right?

I don't know.

>> Then I'm ignoring this too.

>> But I would be happier if they'd be removed, because either  
>> they're superfluous as they're not normative, or they're actually  
>> necessary to understand the protocol, which is even worse because  
>> they're not part of the normative text.

> i think state machines are very useful to understand how the  
> protocol works and to verify that it is working and i think these  
> should be included in the docuemnts

Is it really not possible to express them in ASCII so they can be  
made part of the normative text?

Delivery-date: Fri, 23 Jun 2006 09:09:08 +0000
Date: Fri, 23 Jun 2006 17:08:36 +0800
From: Sam Xia <[email-masked]>
Subject: RE: review of draft-ietf-shim6-failure-detection-03.txt
To: 'Iljitsch van Beijnum' <[email-masked]>, 'Jari Arkko' <[email-masked]>
Cc: 'shim6-wg' <[email-masked]>

Hi, Jari,
    As for section 6.4 (behaviour), maybe it is a better specification form
to seperate the text explaination and move them to the corresponding the
state machine section. Then reader can easily understand what the draft
says.
   And why do you think it is suitable to define the value for send timer
and alive timer as 10s and 3s?
  In my opinion, introduction of shim6 to ipv6 has add the complexity of ip
layer very much; and shim6-failure-detection is not simple. I don't know
what is the last performance.

 Best Regards, Sam Xia 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, June 21, 2006 6:13 PM
> To: Jari Arkko
> Cc: shim6-wg
> Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
> 
> On 20-jun-2006, at 15:45, Jari Arkko wrote:
> 
> >> I'm fairly critical of the current version but I don't 
> want to  waste 
> >> time with an in-depth review if there's going to be a new  version 
> >> within a week anyway.
> 
> > Don't hold back - fire away if you have known problems. You saw the 
> > discussion with John; I'm addressing those comments but will not 
> > rewrite other parts. So it could well be that your comments 
> are still 
> > valid even for -04.
> 
> Ok. First of all, have a look at my message from october 
> 24th, some comments are still valid.
> 
> This draft works per-context exclusively. So if there are 2, 
> 5 or 10 contexts between two hosts, this means 2, 5 or 10 
> times the amount of work is done.
> 
> I think it makes sense to see whether the mechanism can be 
> made to be more general, so that it can be used for other 
> applications as well, ranging from MIP (as indicated in the 
> applicability draft) to tunnel maintenance and maybe even 
> peer-to-peer applications. However, it's important that there 
> is fate sharing between the reachability protocol and the 
> user protocol (shim in our case). I think this can be solved 
> by having the quick reachability verification stuff (= FBD) 
> encapsulated in the user protocol, but let the full path 
> exploration be a protocol of its own or live under ICMPv6 or 
> some such. However, this introduces some issues with knowing 
> whether the same correspondent lives at different addresses.
> 
> In any event, I think just ignoring the possibility that 
> there are multiple contexts between two hosts isn't good 
> enough. The issue of avoiding "reachability probe storms" is 
> somewhat related to this, and also not addressed in the draft.
> 
> Another thing that's missing completely from this draft is a 
> discussion of how to use address pair preference information. 
> This makes it impossible to address traffic engineering needs.
> 
> I believe section 3 (related work) is at best unnecessary and 
> may even confuse the reader. The same is true of much of 
> section 4 (definitions). Implementers know which addresses 
> are usable and which aren't, at least for the most part, so 
> covering this in such detail is superfluous. Things like 
> "Both types of operational pairs could be discovered and 
> monitored through the following mechanisms:" have no place in 
> a protocol specification document, in my opinion. These need 
> to specify what IS, not what COULD be.
> 
> I suggest tightening the use of words like "operational", 
> "work", "reachable". They're mostly used interchangably in the draft.
> 
> 4.5.  Miscellaneous
> 
>     Addresses can become deprecated [3].  When other operational
>     addresses exist, nodes generally wish to move their communications
>     away from the deprecated addresses.
> 
>     Similarly, IPv6 source address selection [6] may guide 
> the selection
>     of a particular source address - destination address pair.
> 
> This doesn't say what shim6 implementers should do. In my opinion:  
> keep using deprecated addresses as the ULID/primary locator 
> as long as possible, but prefer non-deprecated addresses when 
> selecting alternative locators.
> 
> "A "path" is defined as" should probably be in the "definitions"  
> section.
> 
> "when link layer" -> when a link layer
> 
>     1.  The base timing unit for this mechanism is named Keepalive
>         Timeout.  Until a negotiation mechanism to negotiate different
>         values for this timer becomes available, the value (3 seconds)
>         specified in Section 6.5 SHOULD be used.
> 
> Sending a keepalive every 3 seconds? That's way too often, IMO.
> 
>     2.  Whenever outgoing data packets are generated
> 
> Data packets as opposed to what other types of packets?
> 
>     4.  The reception of a REAP keepalive packet leads to stopping the
>         timer associated with the return traffic from the peer.
> 
> So when we receive a keepalive from the other side, _we_ stop 
> sending keepalives? This may be the right thing to do, but 
> it's not obvious to me why. Some explanation would help.
> 
> What if an attacker generates spurious keepalives in order to 
> get us to stop sending keepalives on our side?
> 
>     6.  Send Timeout seconds (10 s; see Section 6.5) after the
>         transmission of a data packet with no return traffic on this
>         context, a full reachability exploration is started.  This
>         timeout period is larger than the Keepalive Timeout to
>         accommodate for lost keepalives and regular 
> variations in round
>         trip times.
> 
> The keepalives are sent at an interval of 3 seconds (or 
> shorter, I imagine that an implementation isn't going to keep 
> an exact timer for each context, any rounding must obviously 
> be in the down direction) and the timeout is 10 seconds. In 
> these 10 seconds you'd normally receive 3 keepalives, while 1 
> is enough to indicate that the other side is still alive. The 
> other 2 are only there in case of packet loss. I think that's 
> excessive. Starting the full reachability exploration because 
> of incidental packet loss isn't such a big deal that it 
> warrants sending three times as many packets as necessary.  
> (Note that this assumes the worst case of a unidirectional 
> transport protocol which isn't exactly the common case.)
> 
> I find it jarring that section 5.5 immediately jumps to 
> examples, before the protocol is fleshed out. Although the 
> examples are referred by using a number, they aren't actually 
> numbered.
> 
> Why would a keepalive need an id field?
> 
> In the first long example B times out once, but then doesn't 
> send more probes until it sees return traffic from A. Why 
> does B stop sending probes?
> 
> I believe that since the id of the last received probe is 
> included, the iseeyou flag is unnecessary.
> 
> Although copying back the last seen id seems to do the job, I 
> can't help but feel that it would be preferable to add timers 
> to reach round trip times and copy back more received ids and 
> also sent ids.  
> This allows the receiver of a probe to determine which of the 
> probes that made it to the other side did so faster, so it 
> can select the address pair with the shortest round trip time.
> 
> Including sent ids along with the addresses the probe with 
> that id was sent to helps the receiver determine that some 
> probes didn't make it (yet). If a probe didn't work in one 
> direction of an address pair, it's reasonable to assume that 
> it may also not work in the other direction and try other pairs first.
> 
> I believe the next example (the fifth, I think?) is flawed 
> because A doesn't send anything after it has sent a data 
> packet, even though it never receives a return packet. The 
> same is true for the example after that.
> 
> When does address pair exploration conclude, both in the 
> cases where there is alternative reachability, and in the 
> case when there appears to be no reachability at all? The 
> exponential backoff isn't described.
> 
> The keepalive is a fairly long packet. I think just a shim 
> header as would be used for data packets but with no ULP 
> following the shim header would be sufficient.
> 
> Requiring random numbers in packets that are sent rather 
> frequently is a bad idea, because it depletes the typically 
> limited amount of entropy that's available for strong random 
> number generation rather quickly and semi-random number 
> generation may be somewhat expensive (and not that good). And 
> I don't see what good an id does in a keepalive anyway... 
> Also, there may be reasons to have non-random numbers, such 
> as ease of lookup.
> 
> The description of the different messages repeats text that 
> is the same for different messages, which is very tedious and 
> makes it likely that people will miss the things that are 
> actually different.  
> (That's why programmer's keyboards don't have ctrl-c/ctrl-v keys:  
> reuse code, don't copy it.)
> 
> The use of options for mandatory fields is awkward.
> 
> "   The node maintains also the Send and Keepalive timers."
> 
> These timers were previously unnamed, it would be better to 
> use their names as soon as they're introduced.
> 
> "   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.  If the node is in the Exploring
>     state it transitions to the ExploringOK state, sends a 
> Probe message
>     with the I See You flag set to 1 (Yes), and starts the Send timer.
>     In the ExploringOK state the node stops the Send timer if it was
>     running, but does not do anything else."
> 
> I don't have a good feeling about this... It's too hard to 
> determine what should be happening. Maybe it would be better 
> rather than go down the list of packets that are 
> sent/received and describe the behavior in each state, to 
> take one state at a time and describe what happens with 
> packets in that state.
> 
>     Upon a timeout on the Keepalive timer the node sends a Keepalive
>     message.  This can only happen in the Operational state.
> 
> Why?
> 
> Why are there different Exploring and ExploringOK states? In 
> both cases, the host needs to continue trying different 
> addresses, it's mostly/only the other side that needs to 
> behave differently when there is successful reachability from 
> them to us but not (yet) from us to them.
> 
>     Garbage collection of SHIM6 contexts terminates contexts that are
>     either unused or have failed due to the inability of the 
> exploration
>     process to find a working pair.
> 
> How is the latter determined?
> 
> This is an important issue. For instance, once that a shim 
> context is rehomed, will it ever return to using the primary locators?
> 
>     In the PDF version of this specification, an informational drawing
>     illustrates the state machine.  Where the text and the drawing
>     differ, the text takes precedence.
> 
> I'm not reviewing the PDF state machine here as the text is normative.
> 
>     A tabular representation of the state machine is shown 
> below.  Like
>     the drawing, this representation is only informational.
> 
> Then I'm ignoring this too.
> 
> But I would be happier if they'd be removed, because either 
> they're superfluous as they're not normative, or they're 
> actually necessary to understand the protocol, which is even 
> worse because they're not part of the normative text.
> 

Delivery-date: Fri, 23 Jun 2006 08:35:14 +0000
Date: Fri, 23 Jun 2006 11:34:13 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>,  "John Loughney (E-mail)" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

A revision -04 that I hope addresses John's comments has been
sent to the secretariat. Until it appears it can be accessed here:

http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-04.txt
 
http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-04.pdf
 
http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-04diff.html

I have not had time to look at your issues Iljitsch yet, but will try to do
so during the weekand.

--Jari

Delivery-date: Thu, 22 Jun 2006 15:20:09 +0000
Content-class: urn:content-classes:message
Subject: HIP section for shim6-applicability draft
Date: Thu, 22 Jun 2006 08:19:38 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "shim6" <[email-masked]>

Below is a proposed section for the shim6-applicability draft.  I've
been through one round of comments with Marcelo and now am posting to
the list for any further comments.

Tom

5.5  shim6 and HIP

shim6 and the Host Identity Protocol (HIP) [RFC4423] are architecturally
similar in that both solutions allow a host, communicating with another
like-enabled host, to use possibly multiple or different locators to
support communications between stable ULIDs.  The signalling exchange to
establish demultiplexing context on both hosts is very similar between
the two protocols.  However, there are a few key differences.  First,
shim6 avoids defining a new namespace for ULIDs, preferring instead to
use a routable locator as a ULID, while HIP uses public keys and hashes
thereof as ULIDs.  The use of a routable locator as ULID better supports
deferred context establishment, application callbacks, and application
referrals, and avoids management and resolution costs of a new
namespace, but requires additional security mechanisms to securely bind
the ULID with the locators.  In HIP, the use of a public key or hash as
a ULID allows the context establishment protocol to use the key to sign
messages that bind the key to the locators.  Second, shim6 uses an
explicit context header on data packets for which the ULIDs differ from
the locators in use (this header is only needed after a failure/rehoming
event occurs), while HIP compresses this context tag into the ESP SPI
field of a BEET-mode security association [BEET].  Third, HIP as
presently defined requires the use of public-key operations in its
signalling exchange and ESP encryption in the data plane, while the use
of shim6 requires neither (if only HBA addresses are used).  HIP by
default provides data protection, while this is non-goal for shim6.

The shim6 working group was chartered to provide a solution to a
specific problem while minimizing deployment disruption, while HIP is
considered more of an experimental approach intended to solve several
more general problems (mobility, multihoming, loss of end-to-end
addressing transparency) through an explicit identifier/locator split.
Communicating hosts that are willing and interested to run HIP (perhaps
extended with shim6's failure detection protocol) likely have no reason
to also run shim6.  In this sense, HIP may be viewed as a possible
long-term evolution or extension of the shim6 architecture, or one
possible implementation of the extended shim6 design [ESD].

Delivery-date: Thu, 22 Jun 2006 15:14:48 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt 
Date: Thu, 22 Jun 2006 18:14:27 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

a couple of comments about this draft...

first of all, the possibility of using the flow label is not =20
considered, why is that? I think it is a good option and it is much =20
cleaner than using the tcp/UDP ports... i would suggest to include it.

Second, i am not sure if using transport ports is the best option since =20=

it would limit the context to a single communication... or are you =20
considering binding multiple port pairs to the same shim context?... in =20=

any case, i guess we would need to flesh out this a bit more in order =20=

to understand how would it work...

Another possibility would be to use IPSec SPI field, a la hip, in case =20=

that the communication is using IPSec

finnally, some details about the actual text...

in section 3 Capabilities exchange it is stated that:
>
>
> When bit 0 is set, the host indicates that it knows how to demultiplex
> packets belonging to the shim context being negotiated under all
> circumstances, so the sender MUST NOT add a shim header to these
> packets.
>
> However, in most cases (as outlined earlier) the cooperation of the
> sender is required to make sure that multiplexing can be done
> successfully, so when bit 0 is set to zero, the shim6 header may only =20=

> be
> suppressed when the hosts involved have at least one capability in
> common. If there is any doubt, the shim6 header MUST NOT be =
suppressed.

i fail to understand this part...

i mean when bit 0 is set, the peer must or must not suppress the header?

Regards, marcelo

>
> El 20/06/2006, a las 23:59, Iljitsch van Beijnum escribi=F3:

> Here my thoughts about suppressing the shim header written up in a =20
> draft.
>
> Begin forwarded message:
>
>> 	Title		: Suppressing the Shim6 Header
>> 	Author(s)	: I. van Beijnum
>> 	Filename	: draft-van-beijnum-shim6-suppress-header-00.txt
>> 	Pages		: 5
>> 	Date		: 2006-6-20
>
>> =09
>> The shim6 protocol defines a header that contains a "context tag" =
that
>> identifies packets as belonging to a certain shim6 context that =
exists
>> between two hosts. It has been suggested that this shim6 header is
>> inserted between the IPv6 header and the upper layer protocol such as
>> TCP in all packets where the shim layer has rewritten the source =20
>> and/or
>> destination address. This document considers the suppression of this
>> header in situations where packets can be successfully demultiplexed =20=

>> by
>> the receiver without it.
>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-van-beijnum-shim6-suppress-=20=

>> header-00.txt
>
> --=20
> I've written another book! http://www.runningipv6.net/
>
>
>

Delivery-date: Thu, 22 Jun 2006 14:59:56 +0000
Cc: Jari Arkko <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Thu, 22 Jun 2006 17:59:23 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

some comments below...

El 21/06/2006, a las 13:13, Iljitsch van Beijnum escribi=F3:

> On 20-jun-2006, at 15:45, Jari Arkko wrote:
>
>>> I'm fairly critical of the current version but I don't want to  =
waste
>>> time with an in-depth review if there's going to be a new  version
>>> within a week anyway.
>
>> Don't hold back - fire away if you have known problems. You saw
>> the discussion with John; I'm addressing those comments but will
>> not rewrite other parts. So it could well be that your comments
>> are still valid even for -04.
>
> Ok. First of all, have a look at my message from october 24th, some =20=

> comments are still valid.
>
> This draft works per-context exclusively. So if there are 2, 5 or 10 =20=

> contexts between two hosts, this means 2, 5 or 10 times the amount of =20=

> work is done.
>

i agree that this would be a nice feature. the problem with this is how =20=

do you identify the peer in such a way that you can probe all the =20
existing contexts. I mean, as of today, the probe/keepalive messages =20
have the context tag, so the peer can identify the context thanks to =20
the context tag. the drawback as you say is that we need as many =20
packets as etablished contexts.

The other option would be to use a single probe/keepalive for all the =20=

contexts between two peers. In order to do that we need a mean to =20
identify the peer so that the receiver of the packet can identify all =20=

the contexts corresponding to the same hosts and apply the received =20
packet to all the contexts.
BAsically this would introduce the notion of endpoint in the shim =20
context/protocol (which is not present today), since today the =20
granularity is ulid pairs (as oposed to endpoint pairs)

in order to do that we need to choose a namespace for identifying the =20=

endpoints and include the endpoint name in the context/context =20
establishment messages.

this would be a considerable change in the protocol i guess, but may be =20=

explored if people deem it relevant.

As a general comment, i am kind of worried about the complexity of the =20=

resulting protocol, including shim protoc and the failure detection =20
protocol and i would really preffer to try to simplify the protocol =20
rather than making it more complex, even if this means loosing some =20
optimization for some cases. I am concerned about having a complex =20
protocol that may become error prone (we already have feedback =20
expressing this concern BTW)

> I think it makes sense to see whether the mechanism can be made to be =20=

> more general, so that it can be used for other applications as well, =20=

> ranging from MIP (as indicated in the applicability draft) to tunnel =20=

> maintenance and maybe even peer-to-peer applications.

i fully agree with this, but i am not sure why do you think this is not =20=

the case already...

>  However, it's important that there is fate sharing between the =20
> reachability protocol and the user protocol (shim in our case). I =20
> think this can be solved by having the quick reachability verification =
=20
> stuff (=3D FBD) encapsulated in the user protocol, but let the full =
path =20
> exploration be a protocol of its own or live under ICMPv6 or some =20
> such.

not sure why do you think this is needed. Defining the protocol =20
messages in a way that they can be included in the shim6 header as well =20=

as in the mobility header or the hip header would be good enough to =20
allow using the failure detection protocol in other protocols.... what =20=

am i missing?

> However, this introduces some issues with knowing whether the same =20
> correspondent lives at different addresses.
>
> In any event, I think just ignoring the possibility that there are =20
> multiple contexts between two hosts isn't good enough. The issue of =20=

> avoiding "reachability probe storms" is somewhat related to this, and =20=

> also not addressed in the draft.
>
> Another thing that's missing completely from this draft is a =20
> discussion of how to use address pair preference information. This =20
> makes it impossible to address traffic engineering needs.
>

well, i have been working on this and i have submitted a draft about =20
how to perform locator pair selection, including reachability =20
information and also preference information from the shim protocol

you can find it at:

http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-=20
selection-00.txt

of course your feedback would be very welcome

> I believe section 3 (related work) is at best unnecessary and may even =
=20
> confuse the reader. The same is true of much of section 4 =20
> (definitions). Implementers know which addresses are usable and which =20=

> aren't, at least for the most part, so covering this in such detail is =
=20
> superfluous. Things like "Both types of operational pairs could be =20
> discovered and monitored through the following mechanisms:" have no =20=

> place in a protocol specification document, in my opinion. These need =20=

> to specify what IS, not what COULD be.
>

i somehow disagree...

i think that the definition section is very useful, because the insight =20=

it provides about the different states of an address and address pairs =20=

are very important. I mean, it makes several very good points, like =20
that an address is not reachable, but an address pair is and the like

with respect to the related work, i agree that this could be moved to =20=

the end of the document (perhaps an appendix)

> I suggest tightening the use of words like "operational", "work", =20
> "reachable". They're mostly used interchangably in the draft.
>

i don't think this is the case.
i find this differences relevant imho

> 4.5.  Miscellaneous
>
>    Addresses can become deprecated [3].  When other operational
>    addresses exist, nodes generally wish to move their communications
>    away from the deprecated addresses.
>
>    Similarly, IPv6 source address selection [6] may guide the =
selection
>    of a particular source address - destination address pair.
>
> This doesn't say what shim6 implementers should do. In my opinion: =20
> keep using deprecated addresses as the ULID/primary locator as long as =
=20
> possible, but prefer non-deprecated addresses when selecting =20
> alternative locators.
>

i think this should belong to the locator selection document...

> "A "path" is defined as" should probably be in the "definitions" =20
> section.
>
> "when link layer" -> when a link layer
>
>    1.  The base timing unit for this mechanism is named Keepalive
>        Timeout.  Until a negotiation mechanism to negotiate different
>        values for this timer becomes available, the value (3 seconds)
>        specified in Section 6.5 SHOULD be used.
>
> Sending a keepalive every 3 seconds? That's way too often, IMO.
>
>    2.  Whenever outgoing data packets are generated
>
> Data packets as opposed to what other types of packets?
>

signalling packets, such as keeplives or probes (is my understanding)

>    4.  The reception of a REAP keepalive packet leads to stopping the
>        timer associated with the return traffic from the peer.
>
> So when we receive a keepalive from the other side, _we_ stop sending =20=

> keepalives?

as i understand it, this means that we are not expecting another packet =20=

(until we send a new packet, of course)

>  This may be the right thing to do, but it's not obvious to me why. =20=

> Some explanation would help.
>
> What if an attacker generates spurious keepalives in order to get us =20=

> to stop sending keepalives on our side?
>
>    6.  Send Timeout seconds (10 s; see Section 6.5) after the
>        transmission of a data packet with no return traffic on this
>        context, a full reachability exploration is started.  This
>        timeout period is larger than the Keepalive Timeout to
>        accommodate for lost keepalives and regular variations in round
>        trip times.
>
> The keepalives are sent at an interval of 3 seconds (or shorter, I =20
> imagine that an implementation isn't going to keep an exact timer for =20=

> each context, any rounding must obviously be in the down direction) =20=

> and the timeout is 10 seconds. In these 10 seconds you'd normally =20
> receive 3 keepalives, while 1 is enough to indicate that the other =20
> side is still alive. The other 2 are only there in case of packet =20
> loss. I think that's excessive.

would you suggest it to reduce it to 2 packets every 10 secs?

I mean, i think this protocol will require quite a lot of fine tunning =20=

based on experience and simulations of the load... i guess that what's =20=

in the current spec are resonable values for the time being (i have no =20=

problem with changing them a bit, but as i said i guess in depth fine =20=

tunning will be needed once we have more experience...)

>  Starting the full reachability exploration because of incidental =20
> packet loss isn't such a big deal that it warrants sending three times =
=20
> as many packets as necessary. (Note that this assumes the worst case =20=

> of a unidirectional transport protocol which isn't exactly the common =20=

> case.)
>
> I find it jarring that section 5.5 immediately jumps to examples, =20
> before the protocol is fleshed out. Although the examples are referred =
=20
> by using a number, they aren't actually numbered.
>
> Why would a keepalive need an id field?
>
> In the first long example B times out once, but then doesn't send more =
=20
> probes until it sees return traffic from A. Why does B stop sending =20=

> probes?
>
> I believe that since the id of the last received probe is included, =20=

> the iseeyou flag is unnecessary.
>

you mean that if the id field is empty, this means iseeyou=3Dno?

> Although copying back the last seen id seems to do the job, I can't =20=

> help but feel that it would be preferable to add timers to reach round =
=20
> trip times and copy back more received ids and also sent ids. This =20
> allows the receiver of a probe to determine which of the probes that =20=

> made it to the other side did so faster, so it can select the address =20=

> pair with the shortest round trip time.

i would suggest to leave this for future work, since it is added =20
complexity and it is not obvious to me that selecting the fastest one =20=

is always the best choice.... (e.g. bandwidth is not considered)

>
> Including sent ids along with the addresses the probe with that id was =
=20
> sent to helps the receiver determine that some probes didn't make it =20=

> (yet). If a probe didn't work in one direction of an address pair, =20
> it's reasonable to assume that it may also not work in the other =20
> direction and try other pairs first.
>

yes, this could be added to the locator selection mechanism

> I believe the next example (the fifth, I think?) is flawed because A =20=

> doesn't send anything after it has sent a data packet, even though it =20=

> never receives a return packet. The same is true for the example after =
=20
> that.
>
> When does address pair exploration conclude, both in the cases where =20=

> there is alternative reachability, and in the case when there appears =20=

> to be no reachability at all? The exponential backoff isn't described.
>
> The keepalive is a fairly long packet. I think just a shim header as =20=

> would be used for data packets but with no ULP following the shim =20
> header would be sufficient.
>

not sure what would you omit from the current packet format... i mean, =20=

we need the context tag and the identifier and we need it to make it =20
extensible in the header.... the only additional filed there is the =20
checksum... are you suggesting we remove that or is there other fields =20=

that you think can be removed?

> Requiring random numbers in packets that are sent rather frequently is =
=20
> a bad idea, because it depletes the typically limited amount of =20
> entropy that's available for strong random number generation rather =20=

> quickly and semi-random number generation may be somewhat expensive =20=

> (and not that good). And I don't see what good an id does in a =20
> keepalive anyway... Also, there may be reasons to have non-random =20
> numbers, such as ease of lookup.
>

i guess this i neeeded to indeed verify that the reply was generated as =20=

a response to the initial packet, this is needed in the case that this =20=

is used as a security mechanism to prevent 3 party flooding attacks i =20=

guess.

> The description of the different messages repeats text that is the =20
> same for different messages, which is very tedious and makes it likely =
=20
> that people will miss the things that are actually different. (That's =20=

> why programmer's keyboards don't have ctrl-c/ctrl-v keys: reuse code, =20=

> don't copy it.)
>
> The use of options for mandatory fields is awkward.
>
> "   The node maintains also the Send and Keepalive timers."
>
> These timers were previously unnamed, it would be better to use their =20=

> names as soon as they're introduced.
>
> "   Upon the reception of a payload packet in the Operational state, =20=

> the
>    node starts the Keepalive timer if it is not yet running, and stops
>    the Send timer if it was running.  If the node is in the Exploring
>    state it transitions to the ExploringOK state, sends a Probe =
message
>    with the I See You flag set to 1 (Yes), and starts the Send timer.
>    In the ExploringOK state the node stops the Send timer if it was
>    running, but does not do anything else."
>
> I don't have a good feeling about this... It's too hard to determine =20=

> what should be happening. Maybe it would be better rather than go down =
=20
> the list of packets that are sent/received and describe the behavior =20=

> in each state, to take one state at a time and describe what happens =20=

> with packets in that state.
>

that would be the state machine i guess, right?

>    Upon a timeout on the Keepalive timer the node sends a Keepalive
>    message.  This can only happen in the Operational state.
>
> Why?
>
> Why are there different Exploring and ExploringOK states? In both =20
> cases, the host needs to continue trying different addresses, it's =20
> mostly/only the other side that needs to behave differently when there =
=20
> is successful reachability from them to us but not (yet) from us to =20=

> them.
>
>    Garbage collection of SHIM6 contexts terminates contexts that are
>    either unused or have failed due to the inability of the =
exploration
>    process to find a working pair.
>
> How is the latter determined?
>
> This is an important issue. For instance, once that a shim context is =20=

> rehomed, will it ever return to using the primary locators?
>
>    In the PDF version of this specification, an informational drawing
>    illustrates the state machine.  Where the text and the drawing
>    differ, the text takes precedence.
>
> I'm not reviewing the PDF state machine here as the text is normative.
>
>    A tabular representation of the state machine is shown below.  Like
>    the drawing, this representation is only informational.
>
> Then I'm ignoring this too.
>
> But I would be happier if they'd be removed, because either they're =20=

> superfluous as they're not normative, or they're actually necessary to =
=20
> understand the protocol, which is even worse because they're not part =20=

> of the normative text.
>
>

i think state machines are very useful to understand how the protocol =20=

works and to verify that it is working and i think these should be =20
included in the docuemnts

Reagrds, marcelo

Delivery-date: Thu, 22 Jun 2006 13:21:01 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt 
Date: Thu, 22 Jun 2006 16:19:54 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 19/06/2006, a las 0:45, Iljitsch van Beijnum escribi=F3:

> On 14-jun-2006, at 9:02, marcelo bagnulo braun wrote:
>
>>> "While the Shim6 protocol does not impose any requirements on the
>>>    disposition of the locators involved in this process"
>
>>> I don't understand what the authors are getting at here. I would=20
>>> strongely suggest actually mentioning the requirements that aren't=20=

>>> imposed.
>
>> the point being made in the sentence is that it would be enough that=20=

>> one of the peers has multiple addresses in order to be able to use=20
>> the shim6 protocol, no matter what those addresses are.
>
> Well, don't tell me that, put it in the draft!  :-)
>

ok, will try to rewrite this more clearly
>
>>> "The Shim6 protocol has other potential applications beyond site
>>>    multi-homing.  For example, since Shim6 is a host-based protocol,=20=

>>> it
>>>    can also be used to support session mobility between interfaces=20=

>>> on a
>>>    multi-homed host."
>
>>> I disagree because shim6 isn't built to support jumping to a=20
>>> previously unknown address, it is assumed that the addresses to be=20=

>>> used after a failure are known before the failure.
>
>> well, you could send an UPDATE message from the new location with the=20=

>> new locator and the validation information for it included in the=20
>> UPDATe message itself. There is no fundamental reason why this cannot=20=

>> be done (we would need to see the actual details of the protocol for=20=

>> this in any case...)
>
> The trouble is that if you say this, people are going to assume that=20=

> this is acutally a good idea, and be upset if it turns out that all=20
> kinds of stuff that is important for mobility isn't in the shim.
>

well, i think we can remove this paragraph. In any case, the clear=20
explanation of what can and cannot be done is included in the mip shim=20=

interaction section...

>>> "   The Shim6 protocol is defined only for IPv6.  However, there is=20=

>>> no
>>>    fundamental reason why a Shim6-like approach could not support=20
>>> IPv4
>>>    addresses as locators, either to provide multi-homing support to
>>>    IPv4-numbered sites"
>
>>> We're already running out of IPv4 addresses with ONE address per=20
>>> host...
>
>> fundamental reason from the protocol prespective... do you want us to=20=

>> change something here?
>
> Personally, I prefer to just say nothing in these cases. If you open=20=

> the can of worms, you have to deal what's inside. On the other hand,=20=

> people may wonder why it's shim_6_ so a good explanation of why this=20=

> is troublesome with IPv4 might be useful. This includes the fact that=20=

> the addresses are too short for CGA/HBA, burning up more addresses and=20=

> possible NAT trouble
>

well, i think it would be useful to support v4 locators (and locators=20
only, i am not suggesting in any way to use v4 ulids...)
so, i would prefer to keep some mention to v4 locators in the document
however, i am ok with including a paragraph explaining the limitations=20=

of such approach, such as that no v4 ulids are supported and that nat=20
traversal would require quite more work.

> There is an additional thing that I noted but didn't bring up in my=20
> previous message:
>
> "  One possibility would be to use MIPv6 capabilities, by simply
>    changing the CoA used as the tunnel endpoint.  However, MIPv6 lacks
>    of failure detection mechanisms that would allow the MN and/or the=20=

> HA
>    to detect the failure and trigger the usage of an alternative
>    address.  Shim6 provides such failure detection protocol, so one
>    possibility would be re-use the failure detection function from the
>    shim6 failure detection protocol in MIPv6.  In this case, the shim6
>    protocol wouldn&#65533;t be used to create shim6 context and =
provide
>    fault tolerance, but just the failure detection functionality would
>    be re-used."
>
> Does this imply we should try to make the reachability/failure=20
> detection protocol more general so it can work even if there is no=20
> shim6?
>

i think this is already somehow the case... but i would like to make a=20=

more detailed analysis of this and see if the failure detection protcol=20=

can be easily used in hip (i guess so) and in mip (i hope so) :-)

regards, marcelo

Delivery-date: Thu, 22 Jun 2006 07:15:01 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Fwd: I-D ACTION:draft-bagnulo-shim6-ingress-filtering-00.txt 
Date: Thu, 22 Jun 2006 10:13:58 +0300

Hi,

we have resubmitted the attached draft for wg consideration.

the goal of the draft is to address the work chartered as:

o Solutions for site exit router selection that work when each ISP
uses ingress filtering, i.e. when the chosen site exit needs to
be related to the source address chosen by the host. This site
exit router selection and the associated address selection
process should work whether or not the peer site supports
the shim6 protocol.

Comments and suggestion about how to move forward with this work are  
really appreciated

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 20 de junio de 2006 22:50:02 GMT+03:00
> Para: [email-masked]
> Cc: Asunto: I-D ACTION:draft-bagnulo-shim6-ingress-filtering-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: Ingress filtering compatibility for IPv6
>                           multihomed sites
> 	Author(s)	: M. Bagnulo, C. Huitema
> 	Filename	: draft-bagnulo-shim6-ingress-filtering-00.txt
> 	Pages		: 17
> 	Date		: 2006-6-20
> 	
>    The note presents a set of mechanisms to provide ingress filtering
>    compatibility for legacy hosts in IPv6 multihomed sites.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress- 
> filtering-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bagnulo-shim6-ingress-filtering-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Wed, 21 Jun 2006 10:14:01 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Wed, 21 Jun 2006 12:13:25 +0200
To: Jari Arkko <[email-masked]>

On 20-jun-2006, at 15:45, Jari Arkko wrote:

>> I'm fairly critical of the current version but I don't want to  waste
>> time with an in-depth review if there's going to be a new  version
>> within a week anyway.

> Don't hold back - fire away if you have known problems. You saw
> the discussion with John; I'm addressing those comments but will
> not rewrite other parts. So it could well be that your comments
> are still valid even for -04.

Ok. First of all, have a look at my message from october 24th, some  
comments are still valid.

This draft works per-context exclusively. So if there are 2, 5 or 10  
contexts between two hosts, this means 2, 5 or 10 times the amount of  
work is done.

I think it makes sense to see whether the mechanism can be made to be  
more general, so that it can be used for other applications as well,  
ranging from MIP (as indicated in the applicability draft) to tunnel  
maintenance and maybe even peer-to-peer applications. However, it's  
important that there is fate sharing between the reachability  
protocol and the user protocol (shim in our case). I think this can  
be solved by having the quick reachability verification stuff (= FBD)  
encapsulated in the user protocol, but let the full path exploration  
be a protocol of its own or live under ICMPv6 or some such. However,  
this introduces some issues with knowing whether the same  
correspondent lives at different addresses.

In any event, I think just ignoring the possibility that there are  
multiple contexts between two hosts isn't good enough. The issue of  
avoiding "reachability probe storms" is somewhat related to this, and  
also not addressed in the draft.

Another thing that's missing completely from this draft is a  
discussion of how to use address pair preference information. This  
makes it impossible to address traffic engineering needs.

I believe section 3 (related work) is at best unnecessary and may  
even confuse the reader. The same is true of much of section 4  
(definitions). Implementers know which addresses are usable and which  
aren't, at least for the most part, so covering this in such detail  
is superfluous. Things like "Both types of operational pairs could be  
discovered and monitored through the following mechanisms:" have no  
place in a protocol specification document, in my opinion. These need  
to specify what IS, not what COULD be.

I suggest tightening the use of words like "operational", "work",  
"reachable". They're mostly used interchangably in the draft.

4.5.  Miscellaneous

    Addresses can become deprecated [3].  When other operational
    addresses exist, nodes generally wish to move their communications
    away from the deprecated addresses.

    Similarly, IPv6 source address selection [6] may guide the selection
    of a particular source address - destination address pair.

This doesn't say what shim6 implementers should do. In my opinion:  
keep using deprecated addresses as the ULID/primary locator as long  
as possible, but prefer non-deprecated addresses when selecting  
alternative locators.

"A "path" is defined as" should probably be in the "definitions"  
section.

"when link layer" -> when a link layer

    1.  The base timing unit for this mechanism is named Keepalive
        Timeout.  Until a negotiation mechanism to negotiate different
        values for this timer becomes available, the value (3 seconds)
        specified in Section 6.5 SHOULD be used.

Sending a keepalive every 3 seconds? That's way too often, IMO.

    2.  Whenever outgoing data packets are generated

Data packets as opposed to what other types of packets?

    4.  The reception of a REAP keepalive packet leads to stopping the
        timer associated with the return traffic from the peer.

So when we receive a keepalive from the other side, _we_ stop sending  
keepalives? This may be the right thing to do, but it's not obvious  
to me why. Some explanation would help.

What if an attacker generates spurious keepalives in order to get us  
to stop sending keepalives on our side?

    6.  Send Timeout seconds (10 s; see Section 6.5) after the
        transmission of a data packet with no return traffic on this
        context, a full reachability exploration is started.  This
        timeout period is larger than the Keepalive Timeout to
        accommodate for lost keepalives and regular variations in round
        trip times.

The keepalives are sent at an interval of 3 seconds (or shorter, I  
imagine that an implementation isn't going to keep an exact timer for  
each context, any rounding must obviously be in the down direction)  
and the timeout is 10 seconds. In these 10 seconds you'd normally  
receive 3 keepalives, while 1 is enough to indicate that the other  
side is still alive. The other 2 are only there in case of packet  
loss. I think that's excessive. Starting the full reachability  
exploration because of incidental packet loss isn't such a big deal  
that it warrants sending three times as many packets as necessary.  
(Note that this assumes the worst case of a unidirectional transport  
protocol which isn't exactly the common case.)

I find it jarring that section 5.5 immediately jumps to examples,  
before the protocol is fleshed out. Although the examples are  
referred by using a number, they aren't actually numbered.

Why would a keepalive need an id field?

In the first long example B times out once, but then doesn't send  
more probes until it sees return traffic from A. Why does B stop  
sending probes?

I believe that since the id of the last received probe is included,  
the iseeyou flag is unnecessary.

Although copying back the last seen id seems to do the job, I can't  
help but feel that it would be preferable to add timers to reach  
round trip times and copy back more received ids and also sent ids.  
This allows the receiver of a probe to determine which of the probes  
that made it to the other side did so faster, so it can select the  
address pair with the shortest round trip time.

Including sent ids along with the addresses the probe with that id  
was sent to helps the receiver determine that some probes didn't make  
it (yet). If a probe didn't work in one direction of an address pair,  
it's reasonable to assume that it may also not work in the other  
direction and try other pairs first.

I believe the next example (the fifth, I think?) is flawed because A  
doesn't send anything after it has sent a data packet, even though it  
never receives a return packet. The same is true for the example  
after that.

When does address pair exploration conclude, both in the cases where  
there is alternative reachability, and in the case when there appears  
to be no reachability at all? The exponential backoff isn't described.

The keepalive is a fairly long packet. I think just a shim header as  
would be used for data packets but with no ULP following the shim  
header would be sufficient.

Requiring random numbers in packets that are sent rather frequently  
is a bad idea, because it depletes the typically limited amount of  
entropy that's available for strong random number generation rather  
quickly and semi-random number generation may be somewhat expensive  
(and not that good). And I don't see what good an id does in a  
keepalive anyway... Also, there may be reasons to have non-random  
numbers, such as ease of lookup.

The description of the different messages repeats text that is the  
same for different messages, which is very tedious and makes it  
likely that people will miss the things that are actually different.  
(That's why programmer's keyboards don't have ctrl-c/ctrl-v keys:  
reuse code, don't copy it.)

The use of options for mandatory fields is awkward.

"   The node maintains also the Send and Keepalive timers."

These timers were previously unnamed, it would be better to use their  
names as soon as they're introduced.

"   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.  If the node is in the Exploring
    state it transitions to the ExploringOK state, sends a Probe message
    with the I See You flag set to 1 (Yes), and starts the Send timer.
    In the ExploringOK state the node stops the Send timer if it was
    running, but does not do anything else."

I don't have a good feeling about this... It's too hard to determine  
what should be happening. Maybe it would be better rather than go  
down the list of packets that are sent/received and describe the  
behavior in each state, to take one state at a time and describe what  
happens with packets in that state.

    Upon a timeout on the Keepalive timer the node sends a Keepalive
    message.  This can only happen in the Operational state.

Why?

Why are there different Exploring and ExploringOK states? In both  
cases, the host needs to continue trying different addresses, it's  
mostly/only the other side that needs to behave differently when  
there is successful reachability from them to us but not (yet) from  
us to them.

    Garbage collection of SHIM6 contexts terminates contexts that are
    either unused or have failed due to the inability of the exploration
    process to find a working pair.

How is the latter determined?

This is an important issue. For instance, once that a shim context is  
rehomed, will it ever return to using the primary locators?

    In the PDF version of this specification, an informational drawing
    illustrates the state machine.  Where the text and the drawing
    differ, the text takes precedence.

I'm not reviewing the PDF state machine here as the text is normative.

    A tabular representation of the state machine is shown below.  Like
    the drawing, this representation is only informational.

Then I'm ignoring this too.

But I would be happier if they'd be removed, because either they're  
superfluous as they're not normative, or they're actually necessary  
to understand the protocol, which is even worse because they're not  
part of the normative text.

Delivery-date: Wed, 21 Jun 2006 09:03:55 +0000
Date: Wed, 21 Jun 2006 11:02:34 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Deguang Le <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Deguang Le wrote:
> Brian E Carpenter schrieb:
...
>>
>> More to the point, I see no value myself in deciding whether it's
>> a "host" multihoming solution or a "site" multihoming solution.
> 
> 
> I agree with what Daniel said in his mails.
> I think they are different since "host" multihoming and "site" 
> multihoming are different scenarios，and might have different goals or 
> benefits. :-)

That is correct. They are different scenarios. That doesn't mean we
need to classify shim6 as one or the other. It works in both
scenarios.

    Brian

Delivery-date: Tue, 20 Jun 2006 20:59:48 +0000
From: Iljitsch van Beijnum <[email-masked]>
Subject: Fwd: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt 
Date: Tue, 20 Jun 2006 22:59:23 +0200
To: shim6-wg <[email-masked]>

Here my thoughts about suppressing the shim header written up in a  
draft.

Begin forwarded message:

> 	Title		: Suppressing the Shim6 Header
> 	Author(s)	: I. van Beijnum
> 	Filename	: draft-van-beijnum-shim6-suppress-header-00.txt
> 	Pages		: 5
> 	Date		: 2006-6-20

> 	
> The shim6 protocol defines a header that contains a "context tag" that
> identifies packets as belonging to a certain shim6 context that exists
> between two hosts. It has been suggested that this shim6 header is
> inserted between the IPv6 header and the upper layer protocol such as
> TCP in all packets where the shim layer has rewritten the source  
> and/or
> destination address. This document considers the suppression of this
> header in situations where packets can be successfully  
> demultiplexed by
> the receiver without it.

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-van-beijnum-shim6- 
> suppress-header-00.txt

-- 
I've written another book! http://www.runningipv6.net/

Delivery-date: Tue, 20 Jun 2006 20:22:50 +0000
Date: Wed, 21 Jun 2006 06:21:49 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: multihoming API draft for SHIM6/HIP

FYI  (the original posting bounced)

    Geoff

From: Miika Komu <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

          Title           : Socket Application Program Interface (API) for
                           Multihoming Shim
          Author(s)       : M. Komu, et al.
          Filename        : draft-sugimoto-multihome-shim-api-00.txt
          Pages           : 30
          Date            : 2006-6-19

     This document specifies a socket API for the multihoming shim layer.
     The API aims to enable interactions between the applications and the
     multihoming shim layer for advanced locator management and also for
     accessing to information about failure detection and path
     exploration.

     This document is based on an assumption that a multhomed host is
     equipped with a 'shim' layer which essentially maintains mappings
     between identifiers and locators at the IP layer.  SHIM6 and HIP are
     examples of this shim layer.  Hence, the API can be commonly used by
     SHIM6 and HIP.

We created another mailing list to avoid excessive cross-posting:

https://www1.ietf.org/mailman/listinfo/multimobsec-api

Delivery-date: Tue, 20 Jun 2006 16:17:42 +0000
Date: Tue, 20 Jun 2006 16:45:14 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt

Iljitsch van Beijnum wrote:

> On 19-mei-2006, at 15:28, Jari Arkko wrote:
>
>> Right. This will be done in -04.
>
>
> The 03 expires at the end of the week. Is there going to be a 04  soon?

-04 is still in the works. Sorry, I've been really slow. But it will
be out this week.

> I'm fairly critical of the current version but I don't want to  waste
> time with an in-depth review if there's going to be a new  version
> within a week anyway.

Don't hold back - fire away if you have known problems. You saw
the discussion with John; I'm addressing those comments but will
not rewrite other parts. So it could well be that your comments
are still valid even for -04.

--Jari

Delivery-date: Tue, 20 Jun 2006 13:43:56 +0000
Date: Tue, 20 Jun 2006 06:43:07 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Iljitsch van Beijnum wrote:

> Hm, maybe it makes sense to build in address rewriting by routers (or 
> middleboxes) after all?
> 
> That way, the hosts handle the security, but routers can easily 
> overwrite source addresses and middleboxes that carry more state could 
> even overwrite destination addresses, as soon as the shim negotiations 
> have completed.

Agreed.
Actually, the rerwriting can happen during the shim context 
establishment as well.

>> Can we do better with respect to traffic engineering without throwing 
>> out security? draft-nordmark-shim6-esd outlines ways in which we can 
>> get the same feedback loop from routers as in GSE.
> 
> This depends largely on whether we accept the proposed requirement that 
> hosts are unable to make any decisions of their own. Do we?

For the initial contact with some degree of id/locator separation we 
don't have much choice but *allow* hosts to make a choice.
The destination identifier will need to map to multiple locators, and 
somebody needs to choose. One could externalize that choice from the 
host (e.g., in some yet-to-be invented scalable policy lookup system) 
but from a deployment perspective it seems we can get more milage out of 
  the hosts picking an initial destination locator and then get feedback 
from the routers (e.g., using locator rewriting by the routers).

    Erik

Delivery-date: Tue, 20 Jun 2006 11:51:27 +0000
Date: Tue, 20 Jun 2006 14:50:40 +0300
From: Shinta Sugimoto <[email-masked]>
To: [email-masked]
Subject: Fw: I-D ACTION:draft-sugimoto-multihome-shim-api-00.txt 

--------_4497E09CAE6206ECF420_MULTIPART_MIXED_
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

FYI. Comments/feedback are welcome!

Regards,
Shinta

Forwarded by Shinta Sugimoto <[email-masked]>
----------------------- Original Message -----------------------
 From:    [email-masked]
 To:      [email-masked]
 Date:    Mon, 19 Jun 2006 15:50:01 -0400
 Subject: I-D ACTION:draft-sugimoto-multihome-shim-api-00.txt 
----

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Socket Application Program Interface (API) for Multihoming Shim
	Author(s)	: M. Komu, et al.
	Filename	: draft-sugimoto-multihome-shim-api-00.txt
	Pages		: 30
	Date		: 2006-6-19
	
   This document specifies a socket API for the multihoming shim layer.
   The API aims to enable interactions between the applications and the
   multihoming shim layer for advanced locator management and also for
   accessing to information about failure detection and path
   exploration.

   This document is based on an assumption that a multhomed host is
   equipped with a 'shim' layer which essentially maintains mappings
   between identifiers and locators at the IP layer.  SHIM6 and HIP are
   examples of this shim layer.  Hence, the API can be commonly used by
   SHIM6 and HIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sugimoto-multihome-shim-api-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sugimoto-multihome-shim-api-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------------- Original Message Ends --------------------

--------_4497E09CAE6206ECF420_MULTIPART_MIXED_
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
Content-Transfer-Encoding: 7bit

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server"; server="[email-masked]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

--OtherAccess
Content-Type: Message/External-body;
 name="draft-sugimoto-multihome-shim-api-00.txt";
 site="ftp.ietf.org";
 access-type="anon-ftp";
 directory="internet-drafts"
Content-Disposition: attachment;
 filename="draft-sugimoto-multihome-shim-api-00.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--------_4497E09CAE6206ECF420_MULTIPART_MIXED_
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------_4497E09CAE6206ECF420_MULTIPART_MIXED_--

Delivery-date: Tue, 20 Jun 2006 11:14:34 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Agenda items for Montreal
Date: Tue, 20 Jun 2006 13:04:13 +0200
To: Kurt Erik Lindqvist <[email-masked]>

On 12-jun-2006, at 4:53, Kurt Erik Lindqvist wrote:

> Its time to start preparing the agenda for the SHIM6 meeting at  
> IETF 66. We've scheduled a 2 hour session for this meeting of this  
> working group, so with this note we are looking to see who has  
> prepared material that they would like to present to the working  
> group that is relevant to our chartered work items.

> Aside from presentations on prepared material,  if you have any  
> topics you'd like to see discussed in the working group meeting,  
> now would be a good time to raise them.

If possible, I'd like to talk briefly about the general direction the  
wg is taking and/or should be taking. This relates to many earlier  
comments I've made on the list on issues such as whether certain  
things should be extensions or part of the base specification, issues  
with shim6 that came up on NANOG and the new situation that will  
exist if/when one or more RIRs decide to allow PI in IPv6.

This should only take 5 minutes but some discussion afterwards may be  
useful. I also think it would be nice if some other people could  
share their views on these topics in a similar fashion.

Delivery-date: Tue, 20 Jun 2006 10:46:21 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: review of draft-ietf-shim6-failure-detection-03.txt
Date: Tue, 20 Jun 2006 12:45:18 +0200
To: Jari Arkko <[email-masked]>

On 19-mei-2006, at 15:28, Jari Arkko wrote:

> Right. This will be done in -04.

The 03 expires at the end of the week. Is there going to be a 04  
soon? I'm fairly critical of the current version but I don't want to  
waste time with an in-depth review if there's going to be a new  
version within a week anyway.

Delivery-date: Mon, 19 Jun 2006 15:25:44 +0000
Date: Mon, 19 Jun 2006 17:24:55 +0200
From: Deguang Le <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Brian E Carpenter schrieb:

> Igor Gashinsky wrote:
> 
>> Shim6 is a host multihoming solution, the only difference is that it 
>> doesn't use multiple NICs and puts the ip addresses all on one interface. 
> 
> 
> I see nothing in shim6 that limits it to a single NIC.
Yes, I agree with you.

As marcelo bagnulo said, there are two types of multihomed hosts:

 > i guess it is mostly a matter of how to define a multihomed host
 >
 > we could say that we have two types of multihomed hosts:
 >
 > - the "strict" multihomed host where the host has multiple physical
 > interfaces
 > - the "loose" multihomed host, where the host has multiple addresses
 >

But, I think shim6 can be applied to both kinds of multihomed hosts.
Is it right? :-)

> 
> More to the point, I see no value myself in deciding whether it's
> a "host" multihoming solution or a "site" multihoming solution.

I agree with what Daniel said in his mails.
I think they are different since "host" multihoming and "site" 
multihoming are different scenarios，and might have different goals or 
benefits. :-)

Cheers
Deguang

> 
>    Brian

Delivery-date: Mon, 19 Jun 2006 12:06:13 +0000
Date: Mon, 19 Jun 2006 14:04:51 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Igor Gashinsky <[email-masked]>
CC: Joe Abley <[email-masked]>, Deguang Le <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Igor Gashinsky wrote:
> Shim6 *is* a host multihoming solution, the only difference is that it 
> doesn't use multiple NICs and puts the ip addresses all on one interface. 

I see nothing in shim6 that limits it to a single NIC.

More to the point, I see no value myself in deciding whether it's
a "host" multihoming solution or a "site" multihoming solution.

    Brian

Delivery-date: Sun, 18 Jun 2006 21:47:27 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt 
Date: Sun, 18 Jun 2006 23:45:56 +0200
To: marcelo bagnulo braun <[email-masked]>

On 14-jun-2006, at 9:02, marcelo bagnulo braun wrote:

>> "While the Shim6 protocol does not impose any requirements on the
>>    disposition of the locators involved in this process"

>> I don't understand what the authors are getting at here. I would  
>> strongely suggest actually mentioning the requirements that aren't  
>> imposed.

> the point being made in the sentence is that it would be enough  
> that one of the peers has multiple addresses in order to be able to  
> use the shim6 protocol, no matter what those addresses are.

Well, don't tell me that, put it in the draft!  :-)

> would it improve rephrasing it as:

>   While the Shim6 protocol does not impose any requirements
>   on the addresses involved in this process

No. People have to guess what you mean, which is pretty much  
impossible because red stripes on the sides aren't required either.  
Either remove this bit or say what you're referring to.

>> In general, the document seems to assume understanding of inter- 
>> domain routing. It is not explained what a locator is except that  
>> on second use it says "locator (address)" which implies that the  
>> two are the same thing. ULID isn't explained.

> ok, we can add a definition section and include those two... is  
> there any other term that you think should be there?

No, but I didn't specifically look for that...

>> "The Shim6 protocol has other potential applications beyond site
>>    multi-homing.  For example, since Shim6 is a host-based  
>> protocol, it
>>    can also be used to support session mobility between interfaces  
>> on a
>>    multi-homed host."

>> I disagree because shim6 isn't built to support jumping to a  
>> previously unknown address, it is assumed that the addresses to be  
>> used after a failure are known before the failure.

> well, you could send an UPDATE message from the new location with  
> the new locator and the validation information for it included in  
> the UPDATe message itself. There is no fundamental reason why this  
> cannot be done (we would need to see the actual details of the  
> protocol for this in any case...)

The trouble is that if you say this, people are going to assume that  
this is acutally a good idea, and be upset if it turns out that all  
kinds of stuff that is important for mobility isn't in the shim.

>> "   The Shim6 protocol is defined only for IPv6.  However, there  
>> is no
>>    fundamental reason why a Shim6-like approach could not support  
>> IPv4
>>    addresses as locators, either to provide multi-homing support to
>>    IPv4-numbered sites"

>> We're already running out of IPv4 addresses with ONE address per  
>> host...

> fundamental reason from the protocol prespective... do you want us  
> to change something here?

Personally, I prefer to just say nothing in these cases. If you open  
the can of worms, you have to deal what's inside. On the other hand,  
people may wonder why it's shim_6_ so a good explanation of why this  
is troublesome with IPv4 might be useful. This includes the fact that  
the addresses are too short for CGA/HBA, burning up more addresses  
and possible NAT trouble

There is an additional thing that I noted but didn't bring up in my  
previous message:

"  One possibility would be to use MIPv6 capabilities, by simply
    changing the CoA used as the tunnel endpoint.  However, MIPv6 lacks
    of failure detection mechanisms that would allow the MN and/or  
the HA
    to detect the failure and trigger the usage of an alternative
    address.  Shim6 provides such failure detection protocol, so one
    possibility would be re-use the failure detection function from the
    shim6 failure detection protocol in MIPv6.  In this case, the shim6
    protocol wouldn&#65533;t be used to create shim6 context and provide
    fault tolerance, but just the failure detection functionality would
    be re-used."

Does this imply we should try to make the reachability/failure  
detection protocol more general so it can work even if there is no  
shim6?

Delivery-date: Fri, 16 Jun 2006 23:33:08 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Sat, 17 Jun 2006 02:32:20 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 16/06/2006, a las 23:31, Iljitsch van Beijnum escribi=F3:

> On 16-jun-2006, at 20:03, marcelo bagnulo braun wrote:
>
>> i guess it is mostly a matter of how to define a multihomed host
>
>> we could say that we have two types of multihomed hosts:
>
>> - the "strict" multihomed host where the host has multiple physical=20=

>> interfaces
>> - the "loose" multihomed host, where the host has multiple addresses
>
>> In the first case it is pretty clear that the host multiple paths to=20=

>> connect to the internet, since the attachment point is different.
>
> Actually, no. You assume that different interfaces will lead to=20
> different off-site paths.

not really, i am assuming that a host with multiple interfaces has=20
multiple paths to connect to the Internet, since the host itself has as=20=

many attachment points as it has interfaces

>  But it's also very possible that different physical interfaces are=20
> just used for redundancy towards the rest of the site,

which is part of the rest of the internet from the host's perspective,=20=

so a host with multiple interfaces has multiple paths to the rest of=20
the internet (that is what i meant..)

anyway, i guess we all understand what we are talking about here, it is=20=

just a matter of terminology

what it is also clear i guess is that terminology we are using is not=20
very precise... :-(

regards, marcelo

>  regardless of whether the site is multihomed or not. This is what I=20=

> consider to be "host multihoming" although I think the current=20
> discussion shows that using this terminology isn't too fruitful. This=20=

> type of host multihoming has no impact on global routing because the=20=

> different addresses for the host are aggregated into a single prefix=20=

> belonging to the site. (Or this all happens at the ethernet link level=20=

> and there's only one IP address. With FDDI there was multihoming at=20
> the physical level, very cool.)
>

Delivery-date: Fri, 16 Jun 2006 21:02:04 +0000
Date: Fri, 16 Jun 2006 17:01:50 -0400 (EDT)
From: Igor Gashinsky <[email-masked]>
To: Joe Abley <[email-masked]>
cc: Deguang Le <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Shim6 *is* a host multihoming solution, the only difference is that it 
doesn't use multiple NICs and puts the ip addresses all on one interface. 
Other then that, it's 100% host multihoming.

-igor

On Fri, 16 Jun 2006, Joe Abley wrote:

:: Hi Deguang,
:: 
:: On 16-Jun-2006, at 12:18, Deguang Le wrote:
:: 
:: > To my understanding, in Shim6 protocol sepcifications, it specifies that
:: > the host is within a multihomed site, so it is regarded as a site
:: > multihoming solution.
:: > 
:: > However, no matter the host is within a multihomed site or not, if only the
:: > host is multihomed and the given solution for solving the multihoming is a
:: > host-based solution. I think it belongs to a host multihoming solution.
:: > 
:: > Besides, there is no fundamental reason why the shim6 solution could not
:: > support the host multihoming.
:: 
:: "Host multihoming" usually refers to a host which has multiple network
:: interfaces. Since this is an issue of lexical convention and not technology,
:: I did a quick google to try and survey common usage of the phrase. I found
:: many references which support this definition, e.g.
:: 
:: http: //foldoc.org/?multihomed+host
:: http: //www.slac.stanford.edu/comp/net/policy/multi-homed.html
:: http: //docs.sun.com/app/docs/doc/806-0916/6ja853998?a=view
:: RFC 1123 section 6.1.3.4
:: RFC 2205 section 3.9
:: 
:: Clearly this is not an exhaustive review, but I will run with it for now :-)
:: 
:: There are aspects of host multihoming which are not part of the shim6
:: specification (e.g. the choice of egress interface and next-hop router that
:: the host uses for a particular outbound datagram). In this sense, shim6 as it
:: stands provides an inadequate specification for host multihoming.
:: 
:: It seems to me that, for this reason, "site multihoming" is a better phrase
:: than "host multihoming". However, given the host-centric approach that shim6
:: takes to site multihoming, additional text to this effect would quite
:: possibly lend clarity to the document in question.
:: 
:: Thoughts?
:: 
:: 
:: Joe
:: 
:: 
:: 

Delivery-date: Fri, 16 Jun 2006 20:38:23 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Fri, 16 Jun 2006 22:38:10 +0200
To: Erik Nordmark <[email-masked]>

On 16-jun-2006, at 18:27, Erik Nordmark wrote:

>> e.g. enforced(!), centrally administered site-wide policy, incl.  
>> traffic
>> engineering inbound and outbound. With no way for hosts to make their
>> own decisions, nothing to (re)configure, no DNS complexity, no  
>> wastage
>> of bandwidth for keepalive, no communication setup delays (the  
>> slow DSL
>> line have already high latency, don't want to add anything to  
>> that) etc.

> [FWIW shim6 doesn't have a communication setup delay. But it does  
> have "do no harm" security which is missing from your list.]

> But the above sounds like asking for a "free lunch" of a BGP with  
> infinite scaling ;-)

Hm, maybe it makes sense to build in address rewriting by routers (or  
middleboxes) after all?

That way, the hosts handle the security, but routers can easily  
overwrite source addresses and middleboxes that carry more state  
could even overwrite destination addresses, as soon as the shim  
negotiations have completed.

> Can we do better with respect to traffic engineering without  
> throwing out security? draft-nordmark-shim6-esd outlines ways in  
> which we can get the same feedback loop from routers as in GSE.

This depends largely on whether we accept the proposed requirement  
that hosts are unable to make any decisions of their own. Do we?

Delivery-date: Fri, 16 Jun 2006 20:32:55 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Fri, 16 Jun 2006 22:31:57 +0200
To: marcelo bagnulo braun <[email-masked]>

On 16-jun-2006, at 20:03, marcelo bagnulo braun wrote:

> i guess it is mostly a matter of how to define a multihomed host

> we could say that we have two types of multihomed hosts:

> - the "strict" multihomed host where the host has multiple physical  
> interfaces
> - the "loose" multihomed host, where the host has multiple addresses

> In the first case it is pretty clear that the host multiple paths  
> to connect to the internet, since the attachment point is different.

Actually, no. You assume that different interfaces will lead to  
different off-site paths. But it's also very possible that different  
physical interfaces are just used for redundancy towards the rest of  
the site, regardless of whether the site is multihomed or not. This  
is what I consider to be "host multihoming" although I think the  
current discussion shows that using this terminology isn't too  
fruitful. This type of host multihoming has no impact on global  
routing because the different addresses for the host are aggregated  
into a single prefix belonging to the site. (Or this all happens at  
the ethernet link level and there's only one IP address. With FDDI  
there was multihoming at the physical level, very cool.)

Delivery-date: Fri, 16 Jun 2006 18:04:03 +0000
Cc: [email-masked], Joe Abley <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Fri, 16 Jun 2006 21:03:47 +0300
To: Deguang Le <[email-masked]>

El 16/06/2006, a las 20:18, Deguang Le escribi=F3:
>
> According to your above definition, a host that is within a multihmed=20=

> site has also multiple network interfaces. =46rom this point of view,=20=

> this situation descirbed in shim6 could also be regarded as host=20
> multihoming. right? :-)
>

i guess it is mostly a matter of how to define a multihomed host

we could say that we have two types of multihomed hosts:

- the "strict" multihomed host where the host has multiple physical=20
interfaces
- the "loose" multihomed host, where the host has multiple addresses

In the first case it is pretty clear that the host multiple paths to=20
connect to the internet, since the attachment point is different.
In the second case, it may have multiple paths, not in the first hop,=20
but afterwards, like the case of multiple ISPs assigning different=20
prefixes to the multihomed site and using different addresses result in=20=

using different site exit paths. However, it should be noted it may be=20=

possible that having multiple addresses does not imply having multiple=20=

paths to the destiantions, (think the case of multiple RFC3041=20
addresses)

So, i guess that the definition of multihomed site is kind of open, and=20=

i think this provides a good flexibility when using the term, but the=20
cost is that some confusions may arise sometimes... :-(

>
>> There are aspects of host multihoming which are not part of the shim6=20=

>>  specification (e.g. the choice of egress interface and next-hop =20
>> router that the host uses for a particular outbound datagram). In =20
>> this sense, shim6 as it stands provides an inadequate specification =20=

>> for host multihoming.
> I think these issues that you point out(e.g. the choice of egress=20
> interface and next-hop  router that the host uses for a particular=20
> outbound datagram) should also be considered in shim6 since shim6 is a=20=

> host-based approach. right? :-)
>

not really, since the host assumes that using a different path will=20
imply using a different ISP (not a different next hop, since there may=20=

be intermediate routers in the site)

regards, marcelo

> Cheers,
> Deguang
>
>
>> It seems to me that, for this reason, "site multihoming" is a better =20=

>> phrase than "host multihoming". However, given the host-centric =20
>> approach that shim6 takes to site multihoming, additional text to =20
>> this effect would quite possibly lend clarity to the document in =20
>> question.
>> Thoughts?
>> Joe
>
>

Delivery-date: Fri, 16 Jun 2006 17:50:22 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Fri, 16 Jun 2006 20:49:40 +0300
To: Deguang Le <[email-masked]>

Hi Deguang,

thanks for your comments

i'll try to answer this one...

El 16/06/2006, a las 19:55, Deguang Le escribi=F3:

> Comments:
>
> 5.1.1.  Multi-homed Home Network
>
>    In this case, the Home Network of the Mobile Node (MN) is multi-
>    homed.  This implies the availability of multiple Home Network
>    prefixes, resulting on multiple HoAs for each MN........
>
>
> Is the "multihomed home network" equal to the multiple home networks?

not really, this means that the home network is multihomed, meaning =20
that the home network is located in a multihomed site, i.e. that the =20
home network is attached to the internet through multiple providers and =20=

that each of these providers has delegated a prefix to the home network

The result is that there are multiple prefix in the home network (as in =20=

any multihomed site) and that each of the prefixes available =20
corresponds to on of the isp providing internet access to the home =20
network

> or what are their differences?
> or could the "multihomed home network" be replaced with the "multiple =20=

> home networks"?
>

i guess not, a mobile node that has multiple (single-homed) home =20
networks is a multihomed mobile node but the home networks are not =20
multihomed

this is kind of messy, i agree

> I think, like a multihomed node, a multihomed home network should =20
> refer to a single home network (i.e. a network prefix) can be =20
> reachable through different paths.
>  Therefore, for a single home network, no matter it is multhomed or =20=

> not, it should be a home network prefix.

> Is my understanding right?
>

almost

a multihomed home network refers as you say to a single home network =20
indeed
but this home network is multihomed, meaning that it has multiple =20
providers, hence multiple prefixes

hope this helps

regards, marcelo

>
> Cheers,
> Deguang
>
>
>
>
> Geoff Huston schrieb:
>> A New Internet-Draft is available from the on-line Internet-Drafts =20=

>> directories.
>> This draft is a work item of the Site Multihoming by IPv6 =20
>> Intermediation Working Group of the IETF.
>>         Title           : Applicability Statement for the Level 3 =20
>> Multihoming Shim Protocol (Shim6)
>>         Author(s)       : M. Bagnulo, J. Abley
>>         Filename        : draft-ietf-shim6-applicability-01.txt
>>         Pages           : 23
>>         Date            : 2006-6-7
>> This document discusses the applicability of the Shim6 IPv6 protocol
>>    element and associated support protocols to provide site =20
>> multihoming
>>    capabilities in IPv6.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability=20
>> -01.txt
>
>

Delivery-date: Fri, 16 Jun 2006 17:19:15 +0000
Date: Fri, 16 Jun 2006 19:18:56 +0200
From: Deguang Le <[email-masked]>
To: Joe Abley <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Hi all, Joe,
Thanks very much!
Please see comments inline...

Joe Abley schrieb:

> Hi Deguang,
> 
> On 16-Jun-2006, at 12:18, Deguang Le wrote:
> 
>> To my understanding, in Shim6 protocol sepcifications, it specifies  
>> that the host is within a multihomed site, so it is regarded as a  
>> site multihoming solution.
>>
>> However, no matter the host is within a multihomed site or not, if  
>> only the host is multihomed and the given solution for solving the  
>> multihoming is a host-based solution. I think it belongs to a host  
>> multihoming solution.
>>
>> Besides, there is no fundamental reason why the shim6 solution  could 
>> not support the host multihoming.
> 
> 
> "Host multihoming" usually refers to a host which has multiple  network 
> interfaces. Since this is an issue of lexical convention and  not 
> technology, I did a quick google to try and survey common usage  of the 
> phrase. I found many references which support this definition,  e.g.
> 
>   http://foldoc.org/?multihomed+host
>   http://www.slac.stanford.edu/comp/net/policy/multi-homed.html
>   http://docs.sun.com/app/docs/doc/806-0916/6ja853998?a=view
>   RFC 1123 section 6.1.3.4
>   RFC 2205 section 3.9
> 
> Clearly this is not an exhaustive review, but I will run with it for  
> now :-)

According to your above definition, a host that is within a multihmed 
site has also multiple network interfaces. From this point of view, this 
situation descirbed in shim6 could also be regarded as host multihoming. 
right? :-)

> 
> There are aspects of host multihoming which are not part of the shim6  
> specification (e.g. the choice of egress interface and next-hop  router 
> that the host uses for a particular outbound datagram). In  this sense, 
> shim6 as it stands provides an inadequate specification  for host 
> multihoming.
I think these issues that you point out(e.g. the choice of egress 
interface and next-hop  router that the host uses for a particular 
outbound datagram) should also be considered in shim6 since shim6 is a 
host-based approach. right? :-)

Cheers,
Deguang

> 
> It seems to me that, for this reason, "site multihoming" is a better  
> phrase than "host multihoming". However, given the host-centric  
> approach that shim6 takes to site multihoming, additional text to  this 
> effect would quite possibly lend clarity to the document in  question.
> 
> Thoughts?
> 
> 
> Joe

Delivery-date: Fri, 16 Jun 2006 16:56:15 +0000
Date: Fri, 16 Jun 2006 18:55:34 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Comments:

5.1.1.  Multi-homed Home Network

    In this case, the Home Network of the Mobile Node (MN) is multi-
    homed.  This implies the availability of multiple Home Network
    prefixes, resulting on multiple HoAs for each MN........

Is the "multihomed home network" equal to the multiple home networks?
or what are their differences?
or could the "multihomed home network" be replaced with the "multiple 
home networks"?

I think, like a multihomed node, a multihomed home network should refer 
to a single home network (i.e. a network prefix) can be reachable 
through different paths. Therefore, for a single home network, no matter 
it is multhomed or not, it should be a home network prefix.

Is my understanding right?

Cheers,
Deguang

Geoff Huston schrieb:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Site Multihoming by IPv6 Intermediation 
> Working Group of the IETF.
> 
>         Title           : Applicability Statement for the Level 3 
> Multihoming Shim Protocol (Shim6)
>         Author(s)       : M. Bagnulo, J. Abley
>         Filename        : draft-ietf-shim6-applicability-01.txt
>         Pages           : 23
>         Date            : 2006-6-7
> 
> This document discusses the applicability of the Shim6 IPv6 protocol
>    element and associated support protocols to provide site multihoming
>    capabilities in IPv6.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt

Delivery-date: Fri, 16 Jun 2006 16:41:47 +0000
Cc: [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Fri, 16 Jun 2006 12:41:22 -0400
To: Deguang Le <[email-masked]>

Hi Deguang,

On 16-Jun-2006, at 12:18, Deguang Le wrote:

> To my understanding, in Shim6 protocol sepcifications, it specifies  
> that the host is within a multihomed site, so it is regarded as a  
> site multihoming solution.
>
> However, no matter the host is within a multihomed site or not, if  
> only the host is multihomed and the given solution for solving the  
> multihoming is a host-based solution. I think it belongs to a host  
> multihoming solution.
>
> Besides, there is no fundamental reason why the shim6 solution  
> could not support the host multihoming.

"Host multihoming" usually refers to a host which has multiple  
network interfaces. Since this is an issue of lexical convention and  
not technology, I did a quick google to try and survey common usage  
of the phrase. I found many references which support this definition,  
e.g.

   http://foldoc.org/?multihomed+host
   http://www.slac.stanford.edu/comp/net/policy/multi-homed.html
   http://docs.sun.com/app/docs/doc/806-0916/6ja853998?a=view
   RFC 1123 section 6.1.3.4
   RFC 2205 section 3.9

Clearly this is not an exhaustive review, but I will run with it for  
now :-)

There are aspects of host multihoming which are not part of the shim6  
specification (e.g. the choice of egress interface and next-hop  
router that the host uses for a particular outbound datagram). In  
this sense, shim6 as it stands provides an inadequate specification  
for host multihoming.

It seems to me that, for this reason, "site multihoming" is a better  
phrase than "host multihoming". However, given the host-centric  
approach that shim6 takes to site multihoming, additional text to  
this effect would quite possibly lend clarity to the document in  
question.

Thoughts?

Joe

Delivery-date: Fri, 16 Jun 2006 16:28:13 +0000
Date: Fri, 16 Jun 2006 09:27:58 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Daniel Roesen wrote:

> e.g. enforced(!), centrally administered site-wide policy, incl. traffic
> engineering inbound and outbound. With no way for hosts to make their
> own decisions, nothing to (re)configure, no DNS complexity, no wastage
> of bandwidth for keepalive, no communication setup delays (the slow DSL
> line have already high latency, don't want to add anything to that) etc.

[FWIW shim6 doesn't have a communication setup delay. But it does have 
"do no harm" security which is missing from your list.]

But the above sounds like asking for a "free lunch" of a BGP with 
infinite scaling ;-)

Even in Mike O'Dell's GSE the host had to choose between multiple 
destination addresses for the peer when sending at least the first packet.
So GSE doesn't seem to satsify the above requirement for the hosts to 
not be able to make their own decisions.
AFAICT any case of id/locator separation there will need be a function 
to pick locators for a given identifier, thus some additional selection 
is needed.

Apart from finding solutions that scale (which drive us towards a 
locator prefix per ISP that a site uses), we also need a solution that 
satisfies the "first, do no harm" security concerns (stated in RFC 4218).

The only deployable security techniques that address those seem to be 
HBA, CGA, and HIP's HITs. Since all of those techniques require that the 
IP identifier (what TCP and UDP sees as the IP address) be of a 
particular form, it either requires involvement of the hosts, or a NAT 
middlebox that will be a Single Point of Failure.

Thus in searching for a site multihoming approach, the requirements 
implied that the host needed to be involved in the security side.

Can we do better with respect to traffic engineering without throwing 
out security? draft-nordmark-shim6-esd outlines ways in which we can get 
the same feedback loop from routers as in GSE.

> I can't see any, as it's a host multihoming solution, not a site
> multihoming solution. The things I'm primarily missing (aside "keep it
> simple on the host end, they don't even get TCP right") are site
> multihoming features that you cannot sanely implement on hosts. But
> I'm happy to be proven wrong. :-)

Sure hope so ;-)

   Erik

Delivery-date: Fri, 16 Jun 2006 16:20:52 +0000
Date: Fri, 16 Jun 2006 18:18:58 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
CC: Joe Abley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

Hi all, Joe,
To my understanding, in Shim6 protocol sepcifications, it specifies that 
the host is within a multihomed site, so it is regarded as a site 
multihoming solution.

However, no matter the host is within a multihomed site or not, if only 
the host is multihomed and the given solution for solving the 
multihoming is a host-based solution. I think it belongs to a host 
multihoming solution.

Besides, there is no fundamental reason why the shim6 solution could not 
support the host multihoming.

Cheers,
Deguang

Joe Abley schrieb:
> 
> On 12-Jun-2006, at 15:53, Daniel Roesen wrote:
> 
>> On Thu, Jun 08, 2006 at 09:28:19AM +1000, Geoff Huston wrote:
>>
>>> This document discusses the applicability of the Shim6 IPv6 protocol
>>>    element and associated support protocols to provide site  multihoming
>>>    capabilities in IPv6.
>>
>>
>> Given that shim6 doesn't provide site multihoming, but only host
>> multihoming, I'd suggest to change this wording to reflect reality.
> 
> 
> The shim6 approach is to provide site multihoming by adding a  
> capability to multi-home to the hosts within the site, as you know.  Do 
> you think that is semantically misleading?
> 
> 
> Joe

Delivery-date: Thu, 15 Jun 2006 06:29:45 +0000
Cc: 'shim6-wg' <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Thu, 15 Jun 2006 09:27:52 +0300
To: Sam Xia <[email-masked]>

Hi Sam,

El 15/06/2006, a las 5:44, Sam Xia escribi=F3:

> Hi, Marchlo,
>    I think it is good to add the definition of Re-homing.
>

ok, will do

regards, marcelo

>  Best Regards, Sam Xia
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of marcelo bagnulo braun
>> Sent: Wednesday, June 14, 2006 3:03 PM
>> To: Iljitsch van Beijnum
>> Cc: shim6-wg
>> Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
>>
>> Hi Iljitsch,
>>
>>
>> thanks for your detailed comments...
>>
>> some replies below...
>>
>> El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribi=F3:
>>
>>> On 8-jun-2006, at 1:28, Geoff Huston wrote:
>>>
>>>> This document discusses the applicability of the Shim6
>> IPv6 protocol
>>>>    element and associated support protocols to provide site
>>>> multihoming
>>>>    capabilities in IPv6.
>>>
>>> Comments:
>>>
>>> "While the Shim6 protocol does not impose any requirements on the
>>>    disposition of the locators involved in this process"
>>>
>>> I don't understand what the authors are getting at here. I would
>>> strongely suggest actually mentioning the requirements that aren't
>>> imposed.
>>>
>>
>> the point being made in the sentence is that it would be
>> enough that one of the peers has multiple addresses in order
>> to be able to use the
>> shim6 protocol, no matter what those addresses are. In
>> particular is not strictly required that those addresses come
>> from different isp (as it is somehow the scenario for which
>> the shim6 was designed for). It would be possible to use the
>> shim6 protocol in a host that has multiple interfaces with
>> one address in each interface and all the addresses with the
>> same prefix for instance... i guess you know all this
>> already, but this is what the draft is trying to communicate
>> (unsuccessfully it seems :-(
>>
>> would it improve rephrasing it as:
>>
>>    While the Shim6 protocol does not impose any requirements
>>    on the addresses involved in this process
>>
>>
>>> "In the scenario illustrated in Figure 1 host H
>> communicates with some
>>>    remote host H'."
>>>
>>> My understanding of using a ' to differentiate between two
>> things is
>>> that it generally means that the two things are very similar, or
>>> represent two stages of the same thing. In this case, that doesn't
>>> apply so it's confusing. Please use another letter for the second
>>> host.
>>>
>>
>> :-)
>>
>> will ddo
>>
>>> In general, the document seems to assume understanding of
>> inter-domain
>>> routing. It is not explained what a locator is except that
>> on second
>>> use it says "locator (address)" which implies that the two are the
>>> same thing. ULID isn't explained.
>>>
>>
>> ok, we can add a definition section and include those two...
>> is there any other term that you think should be there?
>>
>>> "The Shim6 protocol has other potential applications beyond site
>>>    multi-homing.  For example, since Shim6 is a host-based
>> protocol, it
>>>    can also be used to support session mobility between
>> interfaces on a
>>>    multi-homed host."
>>>
>>> I disagree because shim6 isn't built to support jumping to a
>>> previously unknown address, it is assumed that the addresses to be
>>> used after a failure are known before the failure.
>>>
>>
>> well, you could send an UPDATE message from the new location
>> with the new locator and the validation information for it
>> included in the UPDATe message itself. There is no
>> fundamental reason why this cannot be done (we would need to
>> see the actual details of the protocol for this in any case...)
>>
>>> Again my usual dislike of empty lines to skip to the next
>> "page" for a
>>> new heading.
>>>
>>
>> next one will be a "comptact" version....
>>
>>> "   The Shim6 protocol is defined only for IPv6.  However,
>> there is no
>>>    fundamental reason why a Shim6-like approach could not
>> support IPv4
>>>    addresses as locators, either to provide multi-homing support to
>>>    IPv4-numbered sites"
>>>
>>> We're already running out of IPv4 addresses with ONE address per
>>> host...
>>>
>>
>> fundamental reason from the protocol prespective... do you
>> want us to change something here?
>>
>>> "   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
>>>    encoding information in the lower 64 bits of locators.
>> This imposes
>>>    the requirement on address assignment to Shim6-capable
>> hosts that
>>> all
>>>    interface addresses should be able to accommodate 64-bit
>> interface
>>>    identifiers.  This requirement is also imposed by CGA [RFC3972]."
>>>
>>> Not to mention RFC 3513:
>>>
>>> "   For all unicast addresses, except those that start with binary
>>> value
>>>    000, Interface IDs are required to be 64 bits long and to be
>>>    constructed in Modified EUI-64 format."
>>
>> ok, will add the reference
>>
>>>
>>> "4.  Shim6 Capabilities
>>>
>>> 4.1.  Fault Tolerance
>>>
>>> 4.1.1.  Establishing Communications After an Outage"
>>>
>>> Having headers without any text under them is considered bad style.
>>>
>>> "   managed centrally."
>>>
>>> A single line on a new "page" is a "widow" and considered
>> undesirable.
>>> Simarly, the following line is an "orphan":
>>>
>>> "   So, in this configuration, the shim6 protocol is used
>> to provide"
>>>
>>
>> i guess this will be solved with the compact version...
>>
>>
>>> "However, MIPv6 lacks
>>>    of failure detection mechanisms"
>>>
>>> Grammar.
>>>
>>> "In this case, the shim6
>>>    protocol wouldn&#65533;t be used"
>>>
>>> Unicode problem??
>>>
>>
>> i think it is a typo
>>
>>> Extra space after each sentence.
>>>
>>> Altough I feel there are way too many RFCs already, it
>> might make more
>>> sense to move the shim6/MIPv6 interactions to a separate document
>>> because this part just doesn't seem to feel at home here.
>>>
>>
>> well, the whole part about interactions with other parts of
>> the stack seems to belong to this document to me but perhaps
>> we can hear other opinions...
>>
>>> Inconsistent use of "Shim6" and "shim6".
>>>
>>> "It is
>>>    recommended that Shim6 is not used for SCTP sessions,
>> and that path
>>>    maintenance is provided solely by SCTP."
>>>
>>> Hm, I suspect that there are failure modes that aren't
>> handled well by
>>> SCTP that shim6 can handle.
>>
>> i don't know...
>>
>> perhaps unidirectional failures? shim6 can handle a
>> communication with two unidirectional address pairs.... i
>> don't know about sctp...
>>
>>>  And AFAIK SCTP has no security to speak of.
>>>
>>
>> i don't know....
>>
>>> "In this case, the shim6 protocol would be associated to the
>>>    tunnel interface"
>>>
>>> Missing period.
>>>
>>> "6.  Security considerations
>>>
>>>    This section will be completed before publication is requested."
>>>
>>> How about completing it before review is requested?
>>>
>>
>> :-)
>>
>> we do what we can....
>>
>>> "   2.  Application scenarios  . . . . . . . . . . . . . .
>> . . . . . .
>>>  4
>>>    3.  Address Configuration  . . . . . . . . . . . . . . .
>> . . . . .
>>> 6"
>>>
>>> Inconsistent capitalization, happens in multiple places.
>>>
>>> Choice of American/British spelling MAY be inconsistent, I spotted
>>> "behaviour" and "optimization".
>>>
>>
>> regards, marcelo
>>
>>
>>
>>> Iljitsch
>>>
>>
>>
>>
>
>

Delivery-date: Thu, 15 Jun 2006 02:45:43 +0000
Date: Thu, 15 Jun 2006 10:44:44 +0800
From: Sam Xia <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-shim6-applicability-01.txt
To: 'marcelo bagnulo braun' <[email-masked]>, 'Iljitsch van Beijnum' <[email-masked]>
Cc: 'shim6-wg' <[email-masked]>

Hi, Marchlo,=20
   I think it is good to add the definition of Re-homing.

 Best Regards, Sam Xia=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, June 14, 2006 3:03 PM
> To: Iljitsch van Beijnum
> Cc: shim6-wg
> Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
>=20
> Hi Iljitsch,
>=20
>=20
> thanks for your detailed comments...
>=20
> some replies below...
>=20
> El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribi=F3:
>=20
> > On 8-jun-2006, at 1:28, Geoff Huston wrote:
> >
> >> This document discusses the applicability of the Shim6=20
> IPv6 protocol
> >>    element and associated support protocols to provide site=20
> >> multihoming
> >>    capabilities in IPv6.
> >
> > Comments:
> >
> > "While the Shim6 protocol does not impose any requirements on the
> >    disposition of the locators involved in this process"
> >
> > I don't understand what the authors are getting at here. I would=20
> > strongely suggest actually mentioning the requirements that aren't=20
> > imposed.
> >
>=20
> the point being made in the sentence is that it would be=20
> enough that one of the peers has multiple addresses in order=20
> to be able to use the
> shim6 protocol, no matter what those addresses are. In=20
> particular is not strictly required that those addresses come=20
> from different isp (as it is somehow the scenario for which=20
> the shim6 was designed for). It would be possible to use the=20
> shim6 protocol in a host that has multiple interfaces with=20
> one address in each interface and all the addresses with the=20
> same prefix for instance... i guess you know all this=20
> already, but this is what the draft is trying to communicate=20
> (unsuccessfully it seems :-(
>=20
> would it improve rephrasing it as:
>=20
>    While the Shim6 protocol does not impose any requirements
>    on the addresses involved in this process
>=20
>=20
> > "In the scenario illustrated in Figure 1 host H=20
> communicates with some
> >    remote host H'."
> >
> > My understanding of using a ' to differentiate between two=20
> things is=20
> > that it generally means that the two things are very similar, or=20
> > represent two stages of the same thing. In this case, that doesn't=20
> > apply so it's confusing. Please use another letter for the second=20
> > host.
> >
>=20
> :-)
>=20
> will ddo
>=20
> > In general, the document seems to assume understanding of=20
> inter-domain=20
> > routing. It is not explained what a locator is except that=20
> on second=20
> > use it says "locator (address)" which implies that the two are the=20
> > same thing. ULID isn't explained.
> >
>=20
> ok, we can add a definition section and include those two...=20
> is there any other term that you think should be there?
>=20
> > "The Shim6 protocol has other potential applications beyond site
> >    multi-homing.  For example, since Shim6 is a host-based=20
> protocol, it
> >    can also be used to support session mobility between=20
> interfaces on a
> >    multi-homed host."
> >
> > I disagree because shim6 isn't built to support jumping to a=20
> > previously unknown address, it is assumed that the addresses to be=20
> > used after a failure are known before the failure.
> >
>=20
> well, you could send an UPDATE message from the new location=20
> with the new locator and the validation information for it=20
> included in the UPDATe message itself. There is no=20
> fundamental reason why this cannot be done (we would need to=20
> see the actual details of the protocol for this in any case...)
>=20
> > Again my usual dislike of empty lines to skip to the next=20
> "page" for a=20
> > new heading.
> >
>=20
> next one will be a "comptact" version....
>=20
> > "   The Shim6 protocol is defined only for IPv6.  However,=20
> there is no
> >    fundamental reason why a Shim6-like approach could not=20
> support IPv4
> >    addresses as locators, either to provide multi-homing support to
> >    IPv4-numbered sites"
> >
> > We're already running out of IPv4 addresses with ONE address per=20
> > host...
> >
>=20
> fundamental reason from the protocol prespective... do you=20
> want us to change something here?
>=20
> > "   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
> >    encoding information in the lower 64 bits of locators. =20
> This imposes
> >    the requirement on address assignment to Shim6-capable=20
> hosts that=20
> > all
> >    interface addresses should be able to accommodate 64-bit=20
> interface
> >    identifiers.  This requirement is also imposed by CGA [RFC3972]."
> >
> > Not to mention RFC 3513:
> >
> > "   For all unicast addresses, except those that start with binary=20
> > value
> >    000, Interface IDs are required to be 64 bits long and to be
> >    constructed in Modified EUI-64 format."
>=20
> ok, will add the reference
>=20
> >
> > "4.  Shim6 Capabilities
> >
> > 4.1.  Fault Tolerance
> >
> > 4.1.1.  Establishing Communications After an Outage"
> >
> > Having headers without any text under them is considered bad style.
> >
> > "   managed centrally."
> >
> > A single line on a new "page" is a "widow" and considered=20
> undesirable.=20
> > Simarly, the following line is an "orphan":
> >
> > "   So, in this configuration, the shim6 protocol is used=20
> to provide"
> >
>=20
> i guess this will be solved with the compact version...
>=20
>=20
> > "However, MIPv6 lacks
> >    of failure detection mechanisms"
> >
> > Grammar.
> >
> > "In this case, the shim6
> >    protocol wouldn&#65533;t be used"
> >
> > Unicode problem??
> >
>=20
> i think it is a typo
>=20
> > Extra space after each sentence.
> >
> > Altough I feel there are way too many RFCs already, it=20
> might make more=20
> > sense to move the shim6/MIPv6 interactions to a separate document=20
> > because this part just doesn't seem to feel at home here.
> >
>=20
> well, the whole part about interactions with other parts of=20
> the stack seems to belong to this document to me but perhaps=20
> we can hear other opinions...
>=20
> > Inconsistent use of "Shim6" and "shim6".
> >
> > "It is
> >    recommended that Shim6 is not used for SCTP sessions,=20
> and that path
> >    maintenance is provided solely by SCTP."
> >
> > Hm, I suspect that there are failure modes that aren't=20
> handled well by=20
> > SCTP that shim6 can handle.
>=20
> i don't know...
>=20
> perhaps unidirectional failures? shim6 can handle a=20
> communication with two unidirectional address pairs.... i=20
> don't know about sctp...
>=20
> >  And AFAIK SCTP has no security to speak of.
> >
>=20
> i don't know....
>=20
> > "In this case, the shim6 protocol would be associated to the
> >    tunnel interface"
> >
> > Missing period.
> >
> > "6.  Security considerations
> >
> >    This section will be completed before publication is requested."
> >
> > How about completing it before review is requested?
> >
>=20
> :-)
>=20
> we do what we can....
>=20
> > "   2.  Application scenarios  . . . . . . . . . . . . . .=20
> . . . . . .=20
> >  4
> >    3.  Address Configuration  . . . . . . . . . . . . . . .=20
> . . . . . =20
> > 6"
> >
> > Inconsistent capitalization, happens in multiple places.
> >
> > Choice of American/British spelling MAY be inconsistent, I spotted=20
> > "behaviour" and "optimization".
> >
>=20
> regards, marcelo
>=20
>=20
>=20
> > Iljitsch
> >
>=20
>=20
>=20

Delivery-date: Thu, 15 Jun 2006 01:15:43 +0000
Date: Thu, 15 Jun 2006 02:14:17 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Shim6 proxies
Mail-Copies-To: [email-masked]

On Wed, 14 Jun 2006, Erik Nordmark wrote:

> The host (which doesn't have a cert) uses HBA. Looks up 
> www.example.com and gets some IP addresses. The shim6 layer on the 
> host is told the FQDN for the peer.
>
> During the shim6 context establishment TLS is used, which verifies 
> the server's cert.

FWIW: When[1] DNS-Sec is involved, you may well already have 
verified credentials for:

- the example.com zone
- the www.example.com address record
- potentially an RSA public key for www.example.com itself

In which case, as an optimisation, the whole TLS setup and 
verification could be left out - redundant.

1. Which might actually happen within the next few years, as ISC seem
    to be really trying to jump-start deployment.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Well, you know, no matter where you go, there you are.
 		-- Buckaroo Banzai

Delivery-date: Wed, 14 Jun 2006 16:41:15 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim6 proxies
Date: Wed, 14 Jun 2006 18:40:36 +0200
To: Erik Nordmark <[email-masked]>

On 14-jun-2006, at 16:24, Erik Nordmark wrote:

>> shim6 security could work much the same way by tying a certificate  
>> to a ULID, either with or without the intermediate step of an  
>> FQDN. Such a certificate allows a host to prove that it holds a  
>> certain identity, irrespective of the address it's actually using.

> I can see this working, but it can't securely recover a context  
> after a failure failure! This is because there is no trusted  
> relationship between the certificate for the server and the  
> alternate locators of the server.

Does there have to be? You don't have to authenticate the envelope if  
you know the letter is real. But let's see...

> The host (which doesn't have a cert) uses HBA. Looks up  
> www.example.com and gets some IP addresses. The shim6 layer on the  
> host is told the FQDN for the peer.

Really? I don't remember the FQDN playing a part in any shim mechanics.

> During the shim6 context establishment TLS is used, which verifies  
> the server's cert. If the server needs to use a different locator  
> it can use TLS to tell the client the new locator; the shim6 layer  
> needs to verify that the same cert is used for the locator update  
> as was used for the context establishment.

Ok.

> But that happens if the client looses the context and the server  
> needs to send it some data? One would have to fall back on  
> essentially return routability, since the client's shim doesn't  
> remember the FQDN of the server any more (perhaps the application  
> remembers the FQDN but that doesn't help unless we redo all the  
> socket APIs from scratch).

> The worst case is when the client has lost the context and the  
> server needs to contact the client but using a locator that is  
> different than its ULID; in this case even return routability can't  
> be used.

Ok, I see what you mean. One solution would be to forget the FQDN and  
work with ULIDs, but the downside of that is that people need new  
certificates. Alternatively, the FQDN can be recovered from the DNS,  
but without DNSSEC that's not the most secure thing in the world. In  
stuff like HTTPS the important relationship is betweeen the FQDN and  
the certificate, the addresses are mostly incidental. But for the  
shim the FQDN <-> ULID relationship is much more crucial.

I think it would be possible to repair this by having side A create a  
hash of some of side B's stuff along with a secret, and then transmit  
that hash to B. When A then garbage collects and B subsequently  
reconnects, B can say "I presented this to you earlier and you  
believed me then, this hash proves it".

With such a system in place we can also reduce the state that has to  
be kept for an inactive shim context to pretty much just one or more  
alternative locators and  a hash. All other information can be  
recovered from the other side when needed.

Delivery-date: Wed, 14 Jun 2006 14:26:23 +0000
Date: Wed, 14 Jun 2006 07:24:53 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Shim6 proxies

Iljitsch van Beijnum wrote:

> Unless I'm mistaken, if you go to an HTTPS website, what happens is that 
> your browser gets a certificate from the server that proves that the 
> holder of the certificate has a certain identity, such as 
> www.example.com. The browser checks whether the server has the private 
> key for the certificate by sending it a challenge and checks if the 
> identity in question matches the URL, which, I imagine, requires some 
> DNS lookups.
> 
> shim6 security could work much the same way by tying a certificate to a 
> ULID, either with or without the intermediate step of an FQDN. Such a 
> certificate allows a host to prove that it holds a certain identity, 
> irrespective of the address it's actually using. Once you know who 
> you're talking with you can mostly believe them when they say what their 
> locators are, you just need to send a packet to those locators to make 
> sure the same host is present there to avoid the possibility of someone 
> dumping shim6 traffic on an unrelated third party.
> 
> As for the PKI, yes, you need some kind of infrastructure, but it's 
> already there so I don't see the problem, especially for enterprises and 
> content hosters. Most home users don't have a certificate, but they can 
> still use HBA. (Note that in the above scenario only one side (usually 
> the server) needs a certificate.)

I can see this working, but it can't securely recover a context after a 
failure failure! This is because there is no trusted relationship 
between the certificate for the server and the alternate locators of the 
server. (And I have only thought about end-to-end use of this - not 
proxy use - so I don't know if that would add some further complications.)

The host (which doesn't have a cert) uses HBA. Looks up www.example.com 
and gets some IP addresses. The shim6 layer on the host is told the FQDN 
for the peer.

During the shim6 context establishment TLS is used, which verifies the 
server's cert. If the server needs to use a different locator it can use 
TLS to tell the client the new locator; the shim6 layer needs to verify 
that the same cert is used for the locator update as was used for the 
context establishment.

But that happens if the client looses the context and the server needs 
to send it some data? One would have to fall back on essentially return 
routability, since the client's shim doesn't remember the FQDN of the 
server any more (perhaps the application remembers the FQDN but that 
doesn't help unless we redo all the socket APIs from scratch).

The worst case is when the client has lost the context and the server 
needs to contact the client but using a locator that is different than 
its ULID; in this case even return routability can't be used.
Thus it would allow the server to say "my FQDN is www.foo.com and this 
is my cert, and even though I'm using locator X, I also have ULID=Y - 
trust me".

You could argue that the bulk of these problems occur when the "server" 
needs to contact the "client" and that this case isn't important. But if 
we'd want to add this, I think "server" is really "host that has a cert" 
thus we'd want this security scheme to work independently of the 
application layer roles (server vs. client) of the host that has the 
certificate.

So I don't see how the certificate helps, unless there is a global PKI 
which can assertively state the IP addresses of the holder of the 
certificate (and have this somehow be updated when the site/host 
renumbers). Without this, all we seem to get is something analogous to 
anonymous diffie-hellman, and that doesn't help prevent time-shifted 
redirection attacks.

I think one can try to do things using DNS forward+reverse lookups for 
verification of relationships between ULIDs and locators. The old NOID 
draft explored this space. But my personal conclusion was that such an 
approach would be expensive, since to be reasonably secure, the hosts 
would have to do forward+reverse lookup (or reverse+forward) even before 
establishing the shim context. There was also the issue that NOID 
assumed that all communicating parties had correct forward+reverse DNS 
entries.

But it might make sense to look at the possibility of using DNS 
verification for one end and HBA for the other.

    Erik

Delivery-date: Wed, 14 Jun 2006 13:47:47 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 16:47:38 +0300
To: Brian E Carpenter <[email-masked]>

Hi Brian,

El 14/06/2006, a las 16:35, Brian E Carpenter escribi=F3:

> marcelo bagnulo braun wrote:
> Marcelo,
>
> ...
>> So, bottom line is what a HBA/CGA dhcp extension would be useful for=20=

>> and what scenarios/use cases are there for this?
>
> I think it gets pretty hard when you include CGA in the problem. I'm
> concerned about a site of medium size that wants to manage its
> nodes proactively and therefore wants to use DHCPv6, but also wants
> to profit from shim6, with the level of security offered by
> HBA. That seems like a real scenario to me.
>
>

ok, thanks for the feedback,
i will see if i can write a draft with this...

>>>> 5.3.  Shim6 and SCTP
>>>
>>> ...
>>>
>>>>    ...It is
>>>>    recommended that Shim6 is not used for SCTP sessions, and that=20=

>>>> path
>>>>    maintenance is provided solely by SCTP.
>>>
>>>
>>> What is the mechanism, i.e. how does SCTP tell shim6 to do nothing?
>>>
>> well, i think we discussed about this and my understanding was that=20=

>> there was no need for an explicit notification by the sctp to the=20
>> shim (this is implementations specific proabbaly...)
>> That it would be possible for the shim layer to simply not create any=20=

>> context for sctp sockets. In order to do that, the shim6 layer need=20=

>> to have access to the socket information (which i think is=20
>> implementation specific)
>> Besides, it would also be possible to define a DONOT_SHIM socket=20
>> option, but this would require update to use such mechanism
>
> I think you need to say this in the draft. You are assuming that
> a stack that supports SCTP "knows" when a socket is for SCTP, and that
> needs to be confirmed. If not, a socket option seems the only way,
> and IMHO we should say so.
>

ok, we will include some text about this in the next version

thanks,

marcelo

>    Brian
>

Delivery-date: Wed, 14 Jun 2006 13:45:35 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 16:44:58 +0300
To: Daniel Roesen <[email-masked]>

El 14/06/2006, a las 16:25, Daniel Roesen escribi=F3:

> On Wed, Jun 14, 2006 at 03:55:43PM +0300, marcelo bagnulo braun wrote:
>>>> consider a home network consisting of 10 pcs, a couple of printers,
>>>> distributed in 2 LANs and with 2 dsl lines to different providers.
>>>>
>>>> Do you think that the shim6 solution would be suitable for this
>>>> configuration?
>>>
>>> Depends on the requirements. It wouldn't fulfil mine.
>>
>> could you enumerate those requirements that you have that wouldn't be
>> fulfilled by the shim6 solution?
>

> e.g. enforced(!), centrally administered site-wide policy,

so for the 10 pcs network that you have at home, you need centrally=20
enforced policy that cannot be configured in the hosts.... do you=20
really think this is a common requirement for a small home network?

Note well that what the shim6 seems to lack is the centrally=20
enforcement capapbility, not the central management capability (central=20=

mannagement can be introduced by site wide distribution of the rfc3484=20=

polcity table for instance)

>  incl. traffic
> engineering inbound and outbound.

agree with this one
there is some level of TE that you can achieve with a shim like=20
solution, for instance based on address selection. (using RFC3484=20
policy table) such TE tools should provide you stuff like primary=20
backup, load sharing and the like.

agree that maybe there are more advanced TE capabilities that are not=20
provided by the shim, but again, what are the TE capabilities needed=20
for a home network with 10 pcs?

>  With no way for hosts to make their
> own decisions,

why do you need that in a home network with 10 pcs?

>  nothing to (re)configure,

not sure what do you mean about this one...

>  no DNS complexity,

the dns configuration that is required by the shim is to include=20
multiple AAAA records, one per avialble address, do you call this DNS=20
complexity?

>  no wastage
> of bandwidth for keepalive,

well, all fault tolerance solutions imply bandwidth consumption in=20
order to determine whichc links are up and down... not sure how it=20
would be possible to deal with this otherwise... any ideas?

>  no communication setup delays (the slow DSL
> line have already high latency, don't want to add anything to that)=20
> etc.
>

shim6 support deferred setup so no latency in the general case.

>> perhaps there is a way to extend/modify the shim6 solution to cover
>> those...
>
> I can't see any, as it's a host multihoming solution, not a site
> multihoming solution. The things I'm primarily missing (aside "keep it
> simple on the host end, they don't even get TCP right") are site
> multihoming features that you cannot sanely implement on hosts. But
> I'm happy to be proven wrong. :-)
>

where i am heading to: shim6 should be a reasonable solution for small=20=

sites (at least). I accept that big sites may require the enforcement=20
and that this is hardly provided by the shim as it is now, but i would=20=

argue that this is not the case for smallish sites...

Regards, marcelo

>
> Best regards,
> Daniel
>
> --=20
> CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0
>

Delivery-date: Wed, 14 Jun 2006 13:36:07 +0000
Date: Wed, 14 Jun 2006 15:35:47 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

marcelo bagnulo braun wrote:
Marcelo,

...
> 
> So, bottom line is what a HBA/CGA dhcp extension would be useful for and 
> what scenarios/use cases are there for this?

I think it gets pretty hard when you include CGA in the problem. I'm
concerned about a site of medium size that wants to manage its
nodes proactively and therefore wants to use DHCPv6, but also wants
to profit from shim6, with the level of security offered by
HBA. That seems like a real scenario to me.

> 
> 
>>> 5.3.  Shim6 and SCTP
>>
>> ...
>>
>>>    ...It is
>>>    recommended that Shim6 is not used for SCTP sessions, and that path
>>>    maintenance is provided solely by SCTP.
>>
>>
>> What is the mechanism, i.e. how does SCTP tell shim6 to do nothing?
>>
> 
> well, i think we discussed about this and my understanding was that 
> there was no need for an explicit notification by the sctp to the shim 
> (this is implementations specific proabbaly...)
> 
> That it would be possible for the shim layer to simply not create any 
> context for sctp sockets. In order to do that, the shim6 layer need to 
> have access to the socket information (which i think is implementation 
> specific)
> 
> Besides, it would also be possible to define a DONOT_SHIM socket option, 
> but this would require update to use such mechanism
> 

I think you need to say this in the draft. You are assuming that
a stack that supports SCTP "knows" when a socket is for SCTP, and that
needs to be confirmed. If not, a socket option seems the only way,
and IMHO we should say so.

    Brian

Delivery-date: Wed, 14 Jun 2006 13:25:23 +0000
Date: Wed, 14 Jun 2006 15:25:04 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Wed, Jun 14, 2006 at 03:55:43PM +0300, marcelo bagnulo braun wrote:
> >>consider a home network consisting of 10 pcs, a couple of printers,
> >>distributed in 2 LANs and with 2 dsl lines to different providers.
> >>
> >>Do you think that the shim6 solution would be suitable for this
> >>configuration?
> >
> >Depends on the requirements. It wouldn't fulfil mine.
> 
> could you enumerate those requirements that you have that wouldn't be 
> fulfilled by the shim6 solution?

e.g. enforced(!), centrally administered site-wide policy, incl. traffic
engineering inbound and outbound. With no way for hosts to make their
own decisions, nothing to (re)configure, no DNS complexity, no wastage
of bandwidth for keepalive, no communication setup delays (the slow DSL
line have already high latency, don't want to add anything to that) etc.

> perhaps there is a way to extend/modify the shim6 solution to cover 
> those...

I can't see any, as it's a host multihoming solution, not a site
multihoming solution. The things I'm primarily missing (aside "keep it
simple on the host end, they don't even get TCP right") are site
multihoming features that you cannot sanely implement on hosts. But
I'm happy to be proven wrong. :-)

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Wed, 14 Jun 2006 12:55:59 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 15:55:43 +0300
To: Daniel Roesen <[email-masked]>

El 14/06/2006, a las 15:45, Daniel Roesen escribi=F3:

> On Wed, Jun 14, 2006 at 09:14:49AM +0300, marcelo bagnulo braun wrote:
>>> shim6 doesn't deliver anything of that, so it's not a site=20
>>> multihoming
>>> solution.
>>
>> consider a home network consisting of 10 pcs, a couple of printers,
>> distributed in 2 LANs and with 2 dsl lines to different providers.
>>
>> Do you think that the shim6 solution would be suitable for this
>> configuration?
>
> Depends on the requirements. It wouldn't fulfil mine.

could you enumerate those requirements that you have that wouldn't be=20
fulfilled by the shim6 solution?
perhaps there is a way to extend/modify the shim6 solution to cover=20
those...

regards, marcelo

Delivery-date: Wed, 14 Jun 2006 12:45:15 +0000
Date: Wed, 14 Jun 2006 14:45:02 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Wed, Jun 14, 2006 at 09:14:49AM +0300, marcelo bagnulo braun wrote:
> >shim6 doesn't deliver anything of that, so it's not a site multihoming
> >solution.
> 
> consider a home network consisting of 10 pcs, a couple of printers, 
> distributed in 2 LANs and with 2 dsl lines to different providers.
> 
> Do you think that the shim6 solution would be suitable for this 
> configuration?

Depends on the requirements. It wouldn't fulfil mine. But nevermind,
there are surely some who would call the shim6 hack sufficient...

Still it's multiple hosts (potentially all of a site) multihomed, not
a site multihomed. A site multihoming solution would let me multihome
a site without any host inside having a remote clue of being attached
to multiple ISPs. All else would be a clear "layering violation", so
to speak (not talking about OSI layers of course).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Wed, 14 Jun 2006 12:39:32 +0000
Date: Wed, 14 Jun 2006 14:38:53 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Wed, Jun 14, 2006 at 10:30:13AM +0200, Brian E Carpenter wrote:
> >Could you please explain the "site model" of shim6 you are referring to?
> 
> It's pretty clear - if a site has N ISPs it will have N prefixes,
> so each host in the site will have M(<=N) addresses, one under each
> prefix, and those M addresses will form the locator set for
> shim6. None of the addresses in the locator set can be under
> a prefix that isn't one of the N.

And now replace "site" with "host-attached LAN(s)". Where's the "site"
factor gone now?

shim6 is host multihoming. Only shim6ifying each and every device in the
site makes the site multihomed, but only implicitly. And even that only
under the assumption, that all remote communication partners do also
support shim6, otherwise the multihoming is impaired.

Calling a brick a "house building solution" just because it can be
part of a wall is slightly over the top...

But I understand that I won't gain any support for this view here, the
discussion seems to lead nowhere, so I'll rest my case.

Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Wed, 14 Jun 2006 08:30:33 +0000
Date: Wed, 14 Jun 2006 10:30:13 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Daniel Roesen <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

> Could you please explain the "site model" of shim6 you are referring to?

It's pretty clear - if a site has N ISPs it will have N prefixes,
so each host in the site will have M(<=N) addresses, one under each
prefix, and those M addresses will form the locator set for
shim6. None of the addresses in the locator set can be under
a prefix that isn't one of the N.

    Brian

Delivery-date: Wed, 14 Jun 2006 08:08:28 +0000
Cc: "'Daniel Roesen'" <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 10:08:04 +0200
To: Sam Xia <[email-masked]>

On 14-jun-2006, at 5:50, Sam Xia wrote:

> And the most important thing is that shim6
> is designed based on the model figured in this draft. The model is  
> not a
> host multihoming context. Maybe there are some problems when shim6  
> applied
> to pure host multihoming context, I guess. Or the authors don't  
> consider the
> pure host multihoming context carefully.

Well, if we understand "site multihoming" to mean that an entire site  
has two or more different connections to the internet which are  
likely to be to two different ISPs, this is significantly different  
from the situation where a host is connected to the infrastructure  
within the site over two or more links, which I would call "host  
multihoming". For this host multihoming it should be quite doable to  
inject more specifics into the IGP which are then aggregated away  
within the site.

So even though shim6 works on hosts, the way it works makes it a site  
multihoming solution, in my opinion. It wouldn't hurt to explain this  
somewhere, though.

Iljitsch

Delivery-date: Wed, 14 Jun 2006 07:57:04 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 10:56:02 +0300
To: Brian E Carpenter <[email-masked]>

Hi Brain,

thanks for your comments...

El 14/06/2006, a las 9:35, Brian E Carpenter escribi=F3:

> A few personal comments:
>
>> 2.  Application scenarios
> ...
>>    ...This configuration
>>    is intended to provide protection for the end-site in the event of=20=

>> a
>>    failure in some subset of the available transit providers without
>>    requiring the end-site to acquire provider-independent (PI) =
address
>>    space.
>
> I suggest adding:
>
>    or requiring any particular cooperation between the transit=20
> providers.
>
> since this seems to be a significant feature of shim6.
>

ok

>> 3.3.  Address Generation
> ...
>>    Stateful address auto-configuration using DHCP [RFC3315] is not
>>    currently supported, because there is no defined mechanism to=20
>> convey
>>    the CGA Parameter Data Structure and other relevant information=20
>> from
>>    the DHCP server to the host.  The definition of such mechanisms=20
>> seems
>>    to be quite straightforward in the case of the HBA, ...
>
> Is there a plan to perform this work?
>

I had the intention of writing a draft but it was not clear to me how=20
useful would this extension be...

I mean, there are two cases: the HBA and the CGA

The HBA is quite easy to solve, since there is no secret information.=20
However, the resulting addresses would contain a somehow random iid=20
part (as oposed to the case where the dhcp server can assign iid ::1,=20
::2, ::3 and so on to the hosts in the network) so i am not sure why=20
would be interesting to use dhcp in this case... do you have any hints=20=

why this could be interesting?

The CGA case is more complex since there is a private key involved. I=20
this case we can allow the dhcp server to assign a key pair to the=20
host, in which case the dhcp server is actually assigning a address to=20=

the host, but we need a secure channel between the server and the host=20=

and the problem that the server knew the private key at some point in=20
time. THe other option is that the host conveys the public key to the=20
server. In this case, it is less clear what the dhcp server is actually=20=

assigning to the host (since the public key is determined by the host)=20=

and what would this be useful for...

So, bottom line is what a HBA/CGA dhcp extension would be useful for=20
and what scenarios/use cases are there for this?

>> 5.3.  Shim6 and SCTP
> ...
>>    ...It is
>>    recommended that Shim6 is not used for SCTP sessions, and that =
path
>>    maintenance is provided solely by SCTP.
>
> What is the mechanism, i.e. how does SCTP tell shim6 to do nothing?
>

well, i think we discussed about this and my understanding was that=20
there was no need for an explicit notification by the sctp to the shim=20=

(this is implementations specific proabbaly...)

That it would be possible for the shim layer to simply not create any=20
context for sctp sockets. In order to do that, the shim6 layer need to=20=

have access to the socket information (which i think is implementation=20=

specific)

Besides, it would also be possible to define a DONOT_SHIM socket=20
option, but this would require update to use such mechanism

perhaps some other people with more background on this could expand on=20=

this...

regards, marcelo

>     Brian
>
>
>
>

Delivery-date: Wed, 14 Jun 2006 07:03:08 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt 
Date: Wed, 14 Jun 2006 10:02:38 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

thanks for your detailed comments...

some replies below...

El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribi=F3:

> On 8-jun-2006, at 1:28, Geoff Huston wrote:
>
>> This document discusses the applicability of the Shim6 IPv6 protocol
>>    element and associated support protocols to provide site=20
>> multihoming
>>    capabilities in IPv6.
>
> Comments:
>
> "While the Shim6 protocol does not impose any requirements on the
>    disposition of the locators involved in this process"
>
> I don't understand what the authors are getting at here. I would=20
> strongely suggest actually mentioning the requirements that aren't=20
> imposed.
>

the point being made in the sentence is that it would be enough that=20
one of the peers has multiple addresses in order to be able to use the=20=

shim6 protocol, no matter what those addresses are. In particular is=20
not strictly required that those addresses come from different isp (as=20=

it is somehow the scenario for which the shim6 was designed for). It=20
would be possible to use the shim6 protocol in a host that has multiple=20=

interfaces with one address in each interface and all the addresses=20
with the same prefix for instance... i guess you know all this already,=20=

but this is what the draft is trying to communicate (unsuccessfully it=20=

seems :-(

would it improve rephrasing it as:

   While the Shim6 protocol does not impose any requirements
   on the addresses involved in this process

> "In the scenario illustrated in Figure 1 host H communicates with some
>    remote host H'."
>
> My understanding of using a ' to differentiate between two things is=20=

> that it generally means that the two things are very similar, or=20
> represent two stages of the same thing. In this case, that doesn't=20
> apply so it's confusing. Please use another letter for the second=20
> host.
>

:-)

will ddo

> In general, the document seems to assume understanding of inter-domain=20=

> routing. It is not explained what a locator is except that on second=20=

> use it says "locator (address)" which implies that the two are the=20
> same thing. ULID isn't explained.
>

ok, we can add a definition section and include those two... is there=20
any other term that you think should be there?

> "The Shim6 protocol has other potential applications beyond site
>    multi-homing.  For example, since Shim6 is a host-based protocol, =
it
>    can also be used to support session mobility between interfaces on =
a
>    multi-homed host."
>
> I disagree because shim6 isn't built to support jumping to a=20
> previously unknown address, it is assumed that the addresses to be=20
> used after a failure are known before the failure.
>

well, you could send an UPDATE message from the new location with the=20
new locator and the validation information for it included in the=20
UPDATe message itself. There is no fundamental reason why this cannot=20
be done (we would need to see the actual details of the protocol for=20
this in any case...)

> Again my usual dislike of empty lines to skip to the next "page" for a=20=

> new heading.
>

next one will be a "comptact" version....

> "   The Shim6 protocol is defined only for IPv6.  However, there is no
>    fundamental reason why a Shim6-like approach could not support IPv4
>    addresses as locators, either to provide multi-homing support to
>    IPv4-numbered sites"
>
> We're already running out of IPv4 addresses with ONE address per=20
> host...
>

fundamental reason from the protocol prespective... do you want us to=20
change something here?

> "   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
>    encoding information in the lower 64 bits of locators.  This =
imposes
>    the requirement on address assignment to Shim6-capable hosts that=20=

> all
>    interface addresses should be able to accommodate 64-bit interface
>    identifiers.  This requirement is also imposed by CGA [RFC3972]."
>
> Not to mention RFC 3513:
>
> "   For all unicast addresses, except those that start with binary=20
> value
>    000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format."

ok, will add the reference

>
> "4.  Shim6 Capabilities
>
> 4.1.  Fault Tolerance
>
> 4.1.1.  Establishing Communications After an Outage"
>
> Having headers without any text under them is considered bad style.
>
> "   managed centrally."
>
> A single line on a new "page" is a "widow" and considered undesirable.=20=

> Simarly, the following line is an "orphan":
>
> "   So, in this configuration, the shim6 protocol is used to provide"
>

i guess this will be solved with the compact version...

> "However, MIPv6 lacks
>    of failure detection mechanisms"
>
> Grammar.
>
> "In this case, the shim6
>    protocol wouldn&#65533;t be used"
>
> Unicode problem??
>

i think it is a typo

> Extra space after each sentence.
>
> Altough I feel there are way too many RFCs already, it might make more=20=

> sense to move the shim6/MIPv6 interactions to a separate document=20
> because this part just doesn't seem to feel at home here.
>

well, the whole part about interactions with other parts of the stack=20
seems to belong to this document to me
but perhaps we can hear other opinions...

> Inconsistent use of "Shim6" and "shim6".
>
> "It is
>    recommended that Shim6 is not used for SCTP sessions, and that path
>    maintenance is provided solely by SCTP."
>
> Hm, I suspect that there are failure modes that aren't handled well by=20=

> SCTP that shim6 can handle.

i don't know...

perhaps unidirectional failures? shim6 can handle a communication with=20=

two unidirectional address pairs.... i don't know about sctp...

>  And AFAIK SCTP has no security to speak of.
>

i don't know....

> "In this case, the shim6 protocol would be associated to the
>    tunnel interface"
>
> Missing period.
>
> "6.  Security considerations
>
>    This section will be completed before publication is requested."
>
> How about completing it before review is requested?
>

:-)

we do what we can....

> "   2.  Application scenarios  . . . . . . . . . . . . . . . . . . . .=20=

>  4
>    3.  Address Configuration  . . . . . . . . . . . . . . . . . . . . =20=

> 6"
>
> Inconsistent capitalization, happens in multiple places.
>
> Choice of American/British spelling MAY be inconsistent, I spotted=20
> "behaviour" and "optimization".
>

regards, marcelo

> Iljitsch
>

Delivery-date: Wed, 14 Jun 2006 06:35:54 +0000
Date: Wed, 14 Jun 2006 08:35:38 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

A few personal comments:

> 2.  Application scenarios
...
>    ...This configuration
>    is intended to provide protection for the end-site in the event of a
>    failure in some subset of the available transit providers without
>    requiring the end-site to acquire provider-independent (PI) address
>    space.

I suggest adding:

    or requiring any particular cooperation between the transit providers.

since this seems to be a significant feature of shim6.

> 3.3.  Address Generation
...
>    Stateful address auto-configuration using DHCP [RFC3315] is not
>    currently supported, because there is no defined mechanism to convey
>    the CGA Parameter Data Structure and other relevant information from
>    the DHCP server to the host.  The definition of such mechanisms seems
>    to be quite straightforward in the case of the HBA, ...

Is there a plan to perform this work?

> 5.3.  Shim6 and SCTP
...
>    ...It is
>    recommended that Shim6 is not used for SCTP sessions, and that path
>    maintenance is provided solely by SCTP.

What is the mechanism, i.e. how does SCTP tell shim6 to do nothing?

     Brian

Delivery-date: Wed, 14 Jun 2006 06:15:31 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Wed, 14 Jun 2006 09:14:49 +0300
To: Daniel Roesen <[email-masked]>

Hi Daniel,

> shim6 doesn't deliver anything of that, so it's not a site multihoming
> solution.

consider a home network consisting of 10 pcs, a couple of printers, 
distributed in 2 LANs and with 2 dsl lines to different providers.

Do you think that the shim6 solution would be suitable for this 
configuration?

Regards, marcelo

Delivery-date: Wed, 14 Jun 2006 03:51:31 +0000
Date: Wed, 14 Jun 2006 11:50:52 +0800
From: Sam Xia <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-shim6-applicability-01.txt
To: 'Daniel Roesen' <[email-masked]>, [email-masked]

At present, host capable of shim6 doesn't care about anything profiling the
site (according to my knowledge, maybe i am wrong). But in the future, the
host capable of shim6 maybe care. And the most important thing is that shim6
is designed based on the model figured in this draft. The model is not a
host multihoming context. Maybe there are some problems when shim6 applied
to pure host multihoming context, I guess. Or the authors don't consider the
pure host multihoming context carefully.

 Best Regards, Sam Xia 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Daniel Roesen
> Sent: Wednesday, June 14, 2006 10:20 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
> 
> On Wed, Jun 14, 2006 at 09:33:13AM +0800, Sam Xia wrote:
> > Furthermore, the multihoming model for shim6 is a site 
> model, not host 
> > model.
> 
> I cannot follow. Can you outline any attributes of shim6 
> which lean on the concept of "site"? I mean technical and 
> organizational facts, not marketing. As far as I know (please 
> correct me if I'm wrong) shim6 has absolutely zero knowledge 
> of "site". All it knows are the available interface IP 
> addresses. shim6 has no concept of "site" anywhere. It 
> doesn't know any site policy, it doesn't know any site 
> topology, it doesn't know any site identity, it doesn't know 
> about the site's relationship with neighboring sites (or even 
> just uplinks, for that matter). 
> 
> Could you please explain the "site model" of shim6 you are 
> referring to?
> Alternatively, cou you provide a pointer in the protocol 
> specification which explains it?
> 
> Last time I looked it was just a host-based double-NAT with 
> some associated mechanisms to do working end point pair 
> discovery and failover.
> 
> > But I think shim6 maybe be also useful in the host-multihoming 
> > context. Why do the authors not mention the host multihoming at all?
> 
> They do:
> 
>    The Shim6 protocol has other potential applications beyond site
>    multi-homing.  For example, since Shim6 is a host-based 
> protocol, it
>    can also be used to support session mobility between 
> interfaces on a
>    multi-homed host.  A failure in communication between a multi-homed
>    host and some other, remote host might be repaired by 
> selection of a
>    locator associated with a different interface.
> 
> And that's about the only place where the real model is 
> described. This hypothetic "site multihoming" model is only a 
> special case of the above... meaning that more than one 
> prefix is on-link on the same host interface - and makes 
> technically no difference. Host multihoming via a single 
> physical interface, so to say.
> 
> 
> Best regards,
> Daniel
> 
> --
> CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0
> 
> 

Delivery-date: Wed, 14 Jun 2006 02:20:31 +0000
Date: Wed, 14 Jun 2006 04:20:01 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Wed, Jun 14, 2006 at 09:33:13AM +0800, Sam Xia wrote:
> Furthermore, the multihoming model for shim6 is a site model, not
> host model.

I cannot follow. Can you outline any attributes of shim6 which lean on
the concept of "site"? I mean technical and organizational facts, not
marketing. As far as I know (please correct me if I'm wrong) shim6 has
absolutely zero knowledge of "site". All it knows are the available
interface IP addresses. shim6 has no concept of "site" anywhere. It
doesn't know any site policy, it doesn't know any site topology, it
doesn't know any site identity, it doesn't know about the site's
relationship with neighboring sites (or even just uplinks, for that
matter). 

Could you please explain the "site model" of shim6 you are referring to?
Alternatively, cou you provide a pointer in the protocol specification
which explains it?

Last time I looked it was just a host-based double-NAT with some
associated mechanisms to do working end point pair discovery and
failover.

> But I think shim6 maybe be also useful in the host-multihoming
> context. Why do the authors not mention the host multihoming at all?

They do:

   The Shim6 protocol has other potential applications beyond site
   multi-homing.  For example, since Shim6 is a host-based protocol, it
   can also be used to support session mobility between interfaces on a
   multi-homed host.  A failure in communication between a multi-homed
   host and some other, remote host might be repaired by selection of a
   locator associated with a different interface.

And that's about the only place where the real model is described. This
hypothetic "site multihoming" model is only a special case of the
above... meaning that more than one prefix is on-link on the same host
interface - and makes technically no difference. Host multihoming via a
single physical interface, so to say.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Wed, 14 Jun 2006 01:34:24 +0000
Date: Wed, 14 Jun 2006 09:33:13 +0800
From: Sam Xia <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-shim6-applicability-01.txt
To: 'Iljitsch van Beijnum' <[email-masked]>, 'Daniel Roesen' <[email-masked]>
Cc: [email-masked]

Hi,
  Even though shim6 protocol is host-based protocol, shim6 provides the
mutihoming capablity to the hosts in the multihoming site. Furthermore, the
multihoming model for shim6 is a site model, not host model. So I think that
this is the reason that the authors of shim6 call shim6 as a site solution.
  But I think shim6 maybe be also useful in the host-multihoming context.
Why do the authors not mention the host multihoming at all?

 Best Regards, Sam Xia 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, June 13, 2006 10:01 PM
> To: Daniel Roesen
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
> 
> On 13-jun-2006, at 14:35, Daniel Roesen wrote:
> 
> >>> Given that shim6 doesn't provide site multihoming, but only host 
> >>> multihoming, I'd suggest to change this wording to 
> reflect reality.
> 
> >> The shim6 approach is to provide site multihoming by adding a 
> >> capability to multi-home to the hosts within the site, as you know.
> >> Do you think that is semantically misleading?
> 
> > Yes I do. It's not a site being multihomed, it's a host being 
> > multihomed. Which is (to me and many others) a totally different 
> > story.
> 
> Is it hair splitting day already?
> 
> > There is absolutely nothing in shim6 which leans on the "site"
> > concept, no site-wide policy enforcement etc. A site multihoming 
> > solution involves a site-wide routing policy (and it's 
> enforcement), 
> > totally independent of the hosts which are usually to be considered 
> > untrusted and under different administration than the site network.
> 
> > shim6 doesn't deliver anything of that, so it's not a site 
> multihoming 
> > solution. It's a solution for ad-hoc opportunistic host 
> multihoming in 
> > cases where both ends support it and where two or more 
> transitted IPv6 
> > addresses with associated uplinks are available.
> 
> > Unless I've misunderstood all of that. :-)
> 
> My understanding of the whole thing is that either you have 
> two or more cables coming into your SITE or you have two or 
> more cables coming into your HOST. The former should be 
> called site multihoming, the latter host multihoming. 
> (Allowing for wireless multihoming while still making the 
> point as intended is left as an exercise for the
> reader.)
> 
> I don't think that under the above definition shim6 can be 
> considered a mechanism for host multihoming, even though it's 
> not impossible to use it as such. (But then I can run BGP on 
> my laptop and do "host multihoming" in that way too.)
> 

Delivery-date: Tue, 13 Jun 2006 14:00:53 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Tue, 13 Jun 2006 16:00:34 +0200
To: Daniel Roesen <[email-masked]>

On 13-jun-2006, at 14:35, Daniel Roesen wrote:

>>> Given that shim6 doesn't provide site multihoming, but only host
>>> multihoming, I'd suggest to change this wording to reflect reality.

>> The shim6 approach is to provide site multihoming by adding a
>> capability to multi-home to the hosts within the site, as you know.
>> Do you think that is semantically misleading?

> Yes I do. It's not a site being multihomed, it's a host being
> multihomed. Which is (to me and many others) a totally different
> story.

Is it hair splitting day already?

> There is absolutely nothing in shim6 which leans on the "site"
> concept, no site-wide policy enforcement etc. A site multihoming
> solution involves a site-wide routing policy (and it's enforcement),
> totally independent of the hosts which are usually to be considered
> untrusted and under different administration than the site network.

> shim6 doesn't deliver anything of that, so it's not a site multihoming
> solution. It's a solution for ad-hoc opportunistic host multihoming in
> cases where both ends support it and where two or more transitted IPv6
> addresses with associated uplinks are available.

> Unless I've misunderstood all of that. :-)

My understanding of the whole thing is that either you have two or  
more cables coming into your SITE or you have two or more cables  
coming into your HOST. The former should be called site multihoming,  
the latter host multihoming. (Allowing for wireless multihoming while  
still making the point as intended is left as an exercise for the  
reader.)

I don't think that under the above definition shim6 can be considered  
a mechanism for host multihoming, even though it's not impossible to  
use it as such. (But then I can run BGP on my laptop and do "host  
multihoming" in that way too.)

Delivery-date: Tue, 13 Jun 2006 13:53:14 +0000
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt 
Date: Tue, 13 Jun 2006 15:52:31 +0200
To: shim6-wg <[email-masked]>

On 8-jun-2006, at 1:28, Geoff Huston wrote:

> This document discusses the applicability of the Shim6 IPv6 protocol
>    element and associated support protocols to provide site  
> multihoming
>    capabilities in IPv6.

Comments:

"While the Shim6 protocol does not impose any requirements on the
    disposition of the locators involved in this process"

I don't understand what the authors are getting at here. I would  
strongely suggest actually mentioning the requirements that aren't  
imposed.

"In the scenario illustrated in Figure 1 host H communicates with some
    remote host H'."

My understanding of using a ' to differentiate between two things is  
that it generally means that the two things are very similar, or  
represent two stages of the same thing. In this case, that doesn't  
apply so it's confusing. Please use another letter for the second host.

In general, the document seems to assume understanding of inter- 
domain routing. It is not explained what a locator is except that on  
second use it says "locator (address)" which implies that the two are  
the same thing. ULID isn't explained.

"The Shim6 protocol has other potential applications beyond site
    multi-homing.  For example, since Shim6 is a host-based protocol, it
    can also be used to support session mobility between interfaces on a
    multi-homed host."

I disagree because shim6 isn't built to support jumping to a  
previously unknown address, it is assumed that the addresses to be  
used after a failure are known before the failure.

Again my usual dislike of empty lines to skip to the next "page" for  
a new heading.

"   The Shim6 protocol is defined only for IPv6.  However, there is no
    fundamental reason why a Shim6-like approach could not support IPv4
    addresses as locators, either to provide multi-homing support to
    IPv4-numbered sites"

We're already running out of IPv4 addresses with ONE address per host...

"   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
    encoding information in the lower 64 bits of locators.  This imposes
    the requirement on address assignment to Shim6-capable hosts that  
all
    interface addresses should be able to accommodate 64-bit interface
    identifiers.  This requirement is also imposed by CGA [RFC3972]."

Not to mention RFC 3513:

"   For all unicast addresses, except those that start with binary value
    000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format."

"4.  Shim6 Capabilities

4.1.  Fault Tolerance

4.1.1.  Establishing Communications After an Outage"

Having headers without any text under them is considered bad style.

"   managed centrally."

A single line on a new "page" is a "widow" and considered  
undesirable. Simarly, the following line is an "orphan":

"   So, in this configuration, the shim6 protocol is used to provide"

"However, MIPv6 lacks
    of failure detection mechanisms"

Grammar.

"In this case, the shim6
    protocol wouldn&#65533;t be used"

Unicode problem??

Extra space after each sentence.

Altough I feel there are way too many RFCs already, it might make  
more sense to move the shim6/MIPv6 interactions to a separate  
document because this part just doesn't seem to feel at home here.

Inconsistent use of "Shim6" and "shim6".

"It is
    recommended that Shim6 is not used for SCTP sessions, and that path
    maintenance is provided solely by SCTP."

Hm, I suspect that there are failure modes that aren't handled well  
by SCTP that shim6 can handle. And AFAIK SCTP has no security to  
speak of.

"In this case, the shim6 protocol would be associated to the
    tunnel interface"

Missing period.

"6.  Security considerations

    This section will be completed before publication is requested."

How about completing it before review is requested?

"   2.  Application  
scenarios  . . . . . . . . . . . . . . . . . . . .  4
    3.  Address  
Configuration  . . . . . . . . . . . . . . . . . . . .  6"

Inconsistent capitalization, happens in multiple places.

Choice of American/British spelling MAY be inconsistent, I spotted  
"behaviour" and "optimization".

Iljitsch

Delivery-date: Tue, 13 Jun 2006 12:35:50 +0000
Date: Tue, 13 Jun 2006 14:35:35 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Tue, Jun 13, 2006 at 08:14:36AM -0400, Joe Abley wrote:
> >On Thu, Jun 08, 2006 at 09:28:19AM +1000, Geoff Huston wrote:
> >>This document discusses the applicability of the Shim6 IPv6 protocol
> >>   element and associated support protocols to provide site  
> >>multihoming
> >>   capabilities in IPv6.
> >
> >Given that shim6 doesn't provide site multihoming, but only host
> >multihoming, I'd suggest to change this wording to reflect reality.
> 
> The shim6 approach is to provide site multihoming by adding a  
> capability to multi-home to the hosts within the site, as you know.  
> Do you think that is semantically misleading?

Yes I do. It's not a site being multihomed, it's a host being
multihomed. Which is (to me and many others) a totally different
story.

There is absolutely nothing in shim6 which leans on the "site"
concept, no site-wide policy enforcement etc. A site multihoming
solution involves a site-wide routing policy (and it's enforcement),
totally independent of the hosts which are usually to be considered
untrusted and under different administration than the site network.

shim6 doesn't deliver anything of that, so it's not a site multihoming
solution. It's a solution for ad-hoc opportunistic host multihoming in
cases where both ends support it and where two or more transitted IPv6
addresses with associated uplinks are available.

Unless I've misunderstood all of that. :-)

Just because multihoming each host effectively multihomes the site (in
an uncoordinated, ad hoc, unpredictable way) doesn't make it a site
multihoming technique.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Tue, 13 Jun 2006 12:15:34 +0000
Cc: [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Date: Tue, 13 Jun 2006 08:14:36 -0400
To: Daniel Roesen <[email-masked]>

On 12-Jun-2006, at 15:53, Daniel Roesen wrote:

> On Thu, Jun 08, 2006 at 09:28:19AM +1000, Geoff Huston wrote:
>> This document discusses the applicability of the Shim6 IPv6 protocol
>>    element and associated support protocols to provide site  
>> multihoming
>>    capabilities in IPv6.
>
> Given that shim6 doesn't provide site multihoming, but only host
> multihoming, I'd suggest to change this wording to reflect reality.

The shim6 approach is to provide site multihoming by adding a  
capability to multi-home to the hosts within the site, as you know.  
Do you think that is semantically misleading?

Joe

Delivery-date: Tue, 13 Jun 2006 08:38:23 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim6 proxies
Date: Tue, 13 Jun 2006 10:37:22 +0200
To: marcelo bagnulo braun <[email-masked]>

On 13-jun-2006, at 9:22, marcelo bagnulo braun wrote:

>> I think a better way to handle this would be to introduce an  
>> alternative security mechanism, such as in the form of regular X. 
>> 509 certificates that are already widely used for SSL today. (The  
>> fact that this allows people to get around HBA patent claims is a  
>> nice bonus.)

> I am not sure i understand this...

> how would the trust chain between the ULID and the locators would  
> work? through the FQDN?
> how do we bind the fqdn to the identifier? is this in the  
> certificate? do we need a global PKI?

Unless I'm mistaken, if you go to an HTTPS website, what happens is  
that your browser gets a certificate from the server that proves that  
the holder of the certificate has a certain identity, such as  
www.example.com. The browser checks whether the server has the  
private key for the certificate by sending it a challenge and checks  
if the identity in question matches the URL, which, I imagine,  
requires some DNS lookups.

shim6 security could work much the same way by tying a certificate to  
a ULID, either with or without the intermediate step of an FQDN. Such  
a certificate allows a host to prove that it holds a certain  
identity, irrespective of the address it's actually using. Once you  
know who you're talking with you can mostly believe them when they  
say what their locators are, you just need to send a packet to those  
locators to make sure the same host is present there to avoid the  
possibility of someone dumping shim6 traffic on an unrelated third  
party.

As for the PKI, yes, you need some kind of infrastructure, but it's  
already there so I don't see the problem, especially for enterprises  
and content hosters. Most home users don't have a certificate, but  
they can still use HBA. (Note that in the above scenario only one  
side (usually the server) needs a certificate.)

Delivery-date: Tue, 13 Jun 2006 07:23:56 +0000
Cc: [email-masked], Scott Leibrand <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Shim6 proxies
Date: Tue, 13 Jun 2006 10:22:49 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 12/06/2006, a las 17:12, Iljitsch van Beijnum escribi=F3:

> On 18-apr-2006, at 2:22, Erik Nordmark wrote:
>
>>> Either way, the proxy would
>>> process all shim6-tagged traffic for the host, de-shim it as normal,=20=

>>> and
>>> then pass the traffic along to the host's IP instead of passing it=20=

>>> up to
>>> the ULP.
>
>> I think such a proxy could be built, but instead of relying on some=20=

>> complex DHCPv6 coordination of the address assigned to a host, it is=20=

>> much much easier to build and deploy and as IPv6 NAT + shim6 proxy.
>
> I also see problems with getting shim-unaware hosts to receive HBA- or=20=

> CGA-compatible addresses, but I don't think NAT is the solution. It=20
> just breaks too much stuff, and so far, we've managed to keep NAT out=20=

> of IPv6. Also, what's the advantage of IPv6+NAT over IPv4+NAT?
>
> I think a better way to handle this would be to introduce an=20
> alternative security mechanism, such as in the form of regular X.509=20=

> certificates that are already widely used for SSL today. (The fact=20
> that this allows people to get around HBA patent claims is a nice=20
> bonus.)
>
> Although it sucks to add additional stuff to shim6, especially=20
> additional stuff of this complexity, I think it's probably worth it as=20=

> this would allow fully functional proxies without strange tricks. The=20=

> proxy would have a certificate that covers the DNS names used by the=20=

> clients, which is a fairly straightforward thing to get off the ground=20=

> operationally. Hosts would simply use existing address configuration=20=

> techniques (note that most/all DHCPv6 servers/clients don't support=20
> address assignment today) and the proxy would just monitor regular=20
> communication without modifying anything, so backward compatibility=20
> would be good. Only when there seems to be a failure the proxy does a=20=

> shim negotiation and starts remapping the actual address used by the=20=

> client to a locator held by the proxy.
>

I am not sure i understand this...

how would the trust chain between the ULID and the locators would work?=20=

through the FQDN?
how do we bind the fqdn to the identifier? is this in the certificate?=20=

do we need a global PKI?

regards, marcelo

> Being able to move multihoming processing to the edge of the network=20=

> would make shim6 much more viable in enterprise networks. It may also=20=

> be useful on content networks.
>
> Iljitsch
>

Delivery-date: Mon, 12 Jun 2006 19:54:18 +0000
Date: Mon, 12 Jun 2006 21:53:54 +0200
From: Daniel Roesen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Mail-Followup-To: [email-masked]

On Thu, Jun 08, 2006 at 09:28:19AM +1000, Geoff Huston wrote:
> This document discusses the applicability of the Shim6 IPv6 protocol
>    element and associated support protocols to provide site multihoming
>    capabilities in IPv6.

Given that shim6 doesn't provide site multihoming, but only host
multihoming, I'd suggest to change this wording to reflect reality.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

Delivery-date: Mon, 12 Jun 2006 14:13:48 +0000
Cc: Scott Leibrand <[email-masked]>, marcelo bagnulo braun <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim6 proxies
Date: Mon, 12 Jun 2006 16:12:51 +0200
To: Erik Nordmark <[email-masked]>

On 18-apr-2006, at 2:22, Erik Nordmark wrote:

>> Either way, the proxy would
>> process all shim6-tagged traffic for the host, de-shim it as  
>> normal, and
>> then pass the traffic along to the host's IP instead of passing it  
>> up to
>> the ULP.

> I think such a proxy could be built, but instead of relying on some  
> complex DHCPv6 coordination of the address assigned to a host, it  
> is much much easier to build and deploy and as IPv6 NAT + shim6 proxy.

I also see problems with getting shim-unaware hosts to receive HBA-  
or CGA-compatible addresses, but I don't think NAT is the solution.  
It just breaks too much stuff, and so far, we've managed to keep NAT  
out of IPv6. Also, what's the advantage of IPv6+NAT over IPv4+NAT?

I think a better way to handle this would be to introduce an  
alternative security mechanism, such as in the form of regular X.509  
certificates that are already widely used for SSL today. (The fact  
that this allows people to get around HBA patent claims is a nice  
bonus.)

Although it sucks to add additional stuff to shim6, especially  
additional stuff of this complexity, I think it's probably worth it  
as this would allow fully functional proxies without strange tricks.  
The proxy would have a certificate that covers the DNS names used by  
the clients, which is a fairly straightforward thing to get off the  
ground operationally. Hosts would simply use existing address  
configuration techniques (note that most/all DHCPv6 servers/clients  
don't support address assignment today) and the proxy would just  
monitor regular communication without modifying anything, so backward  
compatibility would be good. Only when there seems to be a failure  
the proxy does a shim negotiation and starts remapping the actual  
address used by the client to a locator held by the proxy.

Being able to move multihoming processing to the edge of the network  
would make shim6 much more viable in enterprise networks. It may also  
be useful on content networks.

Iljitsch

Delivery-date: Mon, 12 Jun 2006 02:52:48 +0000
To: shim6-wg <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Agenda items for Montreal
Date: Mon, 12 Jun 2006 04:53:03 +0200

Hi,

Its time to start preparing the agenda for the SHIM6 meeting at IETF  
66. We've scheduled a 2 hour session for this meeting of this working  
group, so with this note we are looking to see who has prepared  
material that they would like to present to the working group that is  
relevant to our chartered work items.

Aside from presentations on prepared material,  if you have any  
topics you'd like to see discussed in the working group meeting, now  
would be a good time to raise them.

many thanks,

   Geoff & Kurtis

(as a reminder of the scope of work here in the SHIM6 WG, our charter  
is at http://www.ietf.org/html.charters/shim6-charter.html)

Delivery-date: Fri, 09 Jun 2006 16:58:13 +0000
From: Joe Abley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt 
Date: Fri, 9 Jun 2006 12:56:57 -0400
To: shim6-wg <[email-masked]>

On 7-Jun-2006, at 19:28, Geoff Huston wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Site Multihoming by IPv6  
> Intermediation Working Group of the IETF.
>
>         Title           : Applicability Statement for the Level 3  
> Multihoming Shim Protocol (Shim6)
>         Author(s)       : M. Bagnulo, J. Abley
>         Filename        : draft-ietf-shim6-applicability-01.txt
>         Pages           : 23
>         Date            : 2006-6-7
>
> This document discusses the applicability of the Shim6 IPv6 protocol
>    element and associated support protocols to provide site  
> multihoming
>    capabilities in IPv6.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-shim6- 
> applicability-01.txt

Thanks, Geoff.

A note to the working group -- this document is incomplete and needs  
work in many areas. However, Marcelo and I decided that it was best  
to ship this revision as-is, so that the general tone and structure  
of the document can be appreciated, rather than risk missing the  
draft cut-off which would make discussion of the draft before and  
during the meeting in Montreal more difficult.

So, while reviews of the content as well as the tone and structure  
would be fabulous to receive, as ever, any observations that "this  
document is not ready to be published" will be met with a terse "yes,  
we know". :-)

Joe

Delivery-date: Fri, 09 Jun 2006 06:49:59 +0000
Date: Fri, 09 Jun 2006 14:49:11 +0800
From: Sam Xia <[email-masked]>
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
To: 'CTO WEN Haibo' <[email-masked]>, 'Geoff Huston' <[email-masked]>, 'Greg Daley' <[email-masked]>
Cc: 'Lawrence Zou' <[email-masked]>, [email-masked]

Hi, haibo,
 I think maybe it is more meaningful to discuss how to select the source
address for the node in the multihoming site.

 Best Regards, Sam Xia=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of CTO WEN Haibo
> Sent: Friday, June 09, 2006 1:12 PM
> To: Geoff Huston; Greg Daley
> Cc: Lawrence Zou; [email-masked]
> Subject: RE: RE: questions about=20
> draft-wen-ipv6-rsra-opt-multihoming-00
>=20
> Yes, I think it's relevant to the shim6 framework.
>=20
> "Shim6 working group will produce specifications for an=20
> IPv6-based site multi-homing solution that inserts a new=20
> sub-layer (shim) into the IP stack of end-system hosts. It=20
> will enable hosts on multi-homed sites to use a set of=20
> provider-assigned IP address prefixes and switch between them=20
> without upsetting transport protocols or applications."
>=20
> With the help of multi-homing information option along with=20
> the prefix information option, shim6 layer can directly find=20
> the matching source address to reach the services from the=20
> desired ISP. Of course, shim6 layer can further try other=20
> source address to reach the service if needed.
>=20
> Haibo
>=20
> > -----Original Message-----
> > From: Geoff Huston [mailto:[email-masked]]
> > Sent: 2006?6?9? 09:00
> > To: CTO WEN Haibo; Greg Daley
> > Cc: Lawrence Zou; [email-masked]
> > Subject: RE: RE: questions about
> > draft-wen-ipv6-rsra-opt-multihoming-00
> >=20
> >=20
> > I am saying that I want to you be aware that shim6 is=20
> approaching the=20
> > problem with a particular framework (shim6) in mind.
> >=20
> > if your contribution is relevant to that framework then of=20
> course this=20
> > is good - if you head off into alternative multi-6=20
> solutions that have=20
> > nothing to do with shim6, then maybe you should reconsider=20
> whether to=20
> > cc shim6 in your notes.
> >=20
> >    Geoff
> >=20
> >=20
> > At 10:46 AM 9/06/2006, CTO WEN Haibo wrote:
> > >Hi Geoff,
> > >
> > >I am wondering the exact meaning of your email. Are you=20
> meaning that=20
> > >some discussions in this particular thread have less relevance with
> > >shim6 or the whole thread has less relelevance to shim6?
> > >
> > >This document tries to solve the source address selection and exit=20
> > >router selection, which is related to the following=20
> working item from=20
> > >the charter of shim:
> > >"In addition to the network layer shim solution, the shim6 WG is=20
> > >specifically chartered to work on:
> > >  Solutions for site exit router selection that work when each ISP=20
> > >uses ingress filtering, i.e. when the chosen site exit needs to be=20
> > >related to the source address chosen by the host. This site exit=20
> > >router selection and the associated address selection=20
> process should=20
> > >work whether or not the peer site supports the shim6 protocol."
> > >
> > >Best regards,
> > >
> > >Haibo
> > >
> > > > -----Original Message-----
> > > > From: Geoff Huston [mailto:[email-masked]]
> > > > Sent: 2006=E5=B9=B46=E6o^9=E6-=A5 07:00
> > > > To: CTO WEN Haibo; Greg Daley
> > > > Cc: Lawrence Zou; [email-masked]
> > > > Subject: RE: RE: questions about
> > > > draft-wen-ipv6-rsra-opt-multihoming-00
> > > >
> > > >
> > > > Could please I remind all of you in this particular mail thread=20
> > > > that the charter of shim6 is to refine and develop one=20
> particular
> > approach to
> > > > multi-homing, and it is definitely NOT to rehash over the
> > > > multi6 discussion
> > > > of "all possible approaches to multihoming".
> > > >
> > > > Accordingly, please think for a second about the=20
> relevance of your=20
> > > > contribution to shim6 before including shim6 in your cc list.
> > > >
> > > > thanks,
> > > >
> > > >    Geoff
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > At 03:38 PM 7/06/2006, CTO WEN Haibo wrote:
> > > > >Hi Greg,
> > > > >
> > > > >Please see the response below. Thanks.
> > > > >
> > > > >Haibo
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Greg Daley [mailto:[email-masked]]
> > > > > > Sent: 2006?=C3=AA6??7=C3=A8? 11:15
> > > > > > To: CTO WEN Haibo
> > > > > > Cc: Lawrence Zou; [email-masked]; [email-masked]
> > > > > > Subject: Re: RE: questions about =20
> > > > > >draft-wen-ipv6-rsra-opt-multihoming-00
> > > > > >....
> > > > > > > The core of this multi-homing information option is
> > > > that to provide
> > > > > > > someextra information along with prefix information
> > > > option to help
> > > > > > > host do
> > > > > > > selection, and the host uses the prefix once it finds
> > > > the matching
> > > > > > > information in multi-homing information option.
> > > > > > > ISP name is a sub-option, ISP name is a generalized
> > > > name, the IPTV
> > > > > > > service provider can name itself as "IPTV", Internet
> > > > > > service provider
> > > > > > > can name itself as "HSI", these names also indicates
> > > > their service
> > > > > > > type.Maybe I haven't made this very clear in the draft.
> > > > Of course,
> > > > > > > any other option can be also defined under this
> > > > architecture, for
> > > > > > > example, what
> > > > > > > kind of service the isp can provide, the qos=20
> parameter, etc.
> > > > > > > Currently,only a few suboption have been defined.
> > > > > > >
> > > > > > > Using this multi-homing option, router can priodically
> > > > advertises
> > > > > > > the
> > > > > > > ISP's ability and related information.
> > > > > > >
> > > > > >
> > > > > > I think it's a much better fit to provide this
> > > > (changeable) operator
> > > > > > related information using 802.21 media independent=20
> information=20
> > > > > > services.
> > > > >802.21 is developing standards to enable handover and
> > > > interoperability
> > > > >between heterogeneous network types including both 802
> > and non 802
> > > > >networks. 802.21 is running below IP layer. However, SAAC
> > > > procedure is
> > > > >running in IP layer.
> > > > >You know, in multi-homing site, each router will advertise
> > > > RA which contains
> > > > >IPv6 prefix information, and the interface of host will
> > > > receive all this
> > > > >RA. The
> > > > >standard Stateless Address Auto-Configuration doesn't
> > provide extra
> > > > >information to help prefix selection. Multi-homing
> > > > informaiton option is for
> > > > >this purpose.
> > > > >
> > > > > >
> > > > > > With respect to access network related configuration
> > information,
> > > > > > we already have DHCPv6 for that, and more specific
> > route options
> > > > > > for Router Discovery.
> > > > >In IPv6, there are two ways for address auto-configuration,
> > > > i.e., stateful
> > > > >configuration based on DHCPv6, and stateless configuration.
> > > > It seems there is
> > > > >no standard that says only DHCPv6 can be used in access
> > > > network and SAAC
> > > > >is forbidden.
> > > > >
> > > > > >
> > > > > > Router Discovery is for prefix and next hop
> > > > determination.  Let's not
> > > > > > make it complicated for other reasons.
> > > > >More information along with prefix information option in RA,
> > > > will help
> > > > >host select
> > > > >the appropriate prefix to form its IPv6 global address and
> > > > also select its
> > > > >exit
> > > > >router. It's not trying to make things complicated. Without
> > > > this effort,
> > > > >host cannot
> > > > >find the appropriate prefix and exit router.
> > > >
> > > >
> > > >
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Fri, 09 Jun 2006 05:13:44 +0000
content-class: urn:content-classes:message
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Fri, 9 Jun 2006 13:12:16 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "Greg Daley" <[email-masked]>
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>

Yes, I think it's relevant to the shim6 framework.

"Shim6 working group will produce specifications for an IPv6-based site=20
multi-homing solution that inserts a new sub-layer (shim) into the IP=20
stack of end-system hosts. It will enable hosts on multi-homed sites to=20
use a set of provider-assigned IP address prefixes and switch between
them without upsetting transport protocols or applications."

With the help of multi-homing information option along with the prefix=20
information option, shim6 layer can directly find the matching source
address to reach the services from the desired ISP. Of course, shim6
layer can further try other source address to reach the service if =
needed.

Haibo

> -----Original Message-----
> From: Geoff Huston [mailto:[email-masked]]
> Sent: 2006?6?9? 09:00
> To: CTO WEN Haibo; Greg Daley
> Cc: Lawrence Zou; [email-masked]
> Subject: RE: RE: questions about=20
> draft-wen-ipv6-rsra-opt-multihoming-00
>=20
>=20
> I am saying that I want to you be aware that shim6 is approaching the=20
> problem with a particular framework (shim6) in mind.
>=20
> if your contribution is relevant to that framework then of=20
> course this is=20
> good - if you head off into alternative multi-6 solutions=20
> that have nothing=20
> to do with shim6, then maybe you should reconsider whether to=20
> cc shim6 in=20
> your notes.
>=20
>    Geoff
>=20
>=20
> At 10:46 AM 9/06/2006, CTO WEN Haibo wrote:
> >Hi Geoff,
> >
> >I am wondering the exact meaning of your email. Are you meaning that
> >some discussions in this particular thread have less relevance with
> >shim6 or the whole thread has less relelevance to shim6?
> >
> >This document tries to solve the source address selection and exit
> >router selection, which is related to the following working item from
> >the charter of shim:
> >"In addition to the network layer shim solution, the shim6 WG is
> >specifically chartered to work on:
> >  Solutions for site exit router selection that work when each ISP
> >uses ingress filtering, i.e. when the chosen site exit needs to
> >be related to the source address chosen by the host. This site
> >exit router selection and the associated address selection
> >process should work whether or not the peer site supports
> >the shim6 protocol."
> >
> >Best regards,
> >
> >Haibo
> >
> > > -----Original Message-----
> > > From: Geoff Huston [mailto:[email-masked]]
> > > Sent: 2006=E5=B9=B46=E6o^9=E6-=A5 07:00
> > > To: CTO WEN Haibo; Greg Daley
> > > Cc: Lawrence Zou; [email-masked]
> > > Subject: RE: RE: questions about
> > > draft-wen-ipv6-rsra-opt-multihoming-00
> > >
> > >
> > > Could please I remind all of you in this particular mail
> > > thread that the
> > > charter of shim6 is to refine and develop one particular=20
> approach to
> > > multi-homing, and it is definitely NOT to rehash over the
> > > multi6 discussion
> > > of "all possible approaches to multihoming".
> > >
> > > Accordingly, please think for a second about the relevance of your
> > > contribution to shim6 before including shim6 in your cc list.
> > >
> > > thanks,
> > >
> > >    Geoff
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > At 03:38 PM 7/06/2006, CTO WEN Haibo wrote:
> > > >Hi Greg,
> > > >
> > > >Please see the response below. Thanks.
> > > >
> > > >Haibo
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg Daley [mailto:[email-masked]]
> > > > > Sent: 2006?=C3=AA6??7=C3=A8? 11:15
> > > > > To: CTO WEN Haibo
> > > > > Cc: Lawrence Zou; [email-masked]; [email-masked]
> > > > > Subject: Re: RE: questions about
> > > > > draft-wen-ipv6-rsra-opt-multihoming-00
> > > > >....
> > > > > > The core of this multi-homing information option is
> > > that to provide
> > > > > > someextra information along with prefix information
> > > option to help
> > > > > > host do
> > > > > > selection, and the host uses the prefix once it finds
> > > the matching
> > > > > > information in multi-homing information option.
> > > > > > ISP name is a sub-option, ISP name is a generalized
> > > name, the IPTV
> > > > > > service provider can name itself as "IPTV", Internet
> > > > > service provider
> > > > > > can name itself as "HSI", these names also indicates
> > > their service
> > > > > > type.Maybe I haven't made this very clear in the draft.
> > > Of course,
> > > > > > any other option can be also defined under this
> > > architecture, for
> > > > > > example, what
> > > > > > kind of service the isp can provide, the qos parameter, etc.
> > > > > > Currently,only a few suboption have been defined.
> > > > > >
> > > > > > Using this multi-homing option, router can priodically
> > > advertises
> > > > > > the
> > > > > > ISP's ability and related information.
> > > > > >
> > > > >
> > > > > I think it's a much better fit to provide this
> > > (changeable) operator
> > > > > related information using 802.21 media independent
> > > > > information services.
> > > >802.21 is developing standards to enable handover and
> > > interoperability
> > > >between heterogeneous network types including both 802=20
> and non 802
> > > >networks. 802.21 is running below IP layer. However, SAAC
> > > procedure is
> > > >running in IP layer.
> > > >You know, in multi-homing site, each router will advertise
> > > RA which contains
> > > >IPv6 prefix information, and the interface of host will
> > > receive all this
> > > >RA. The
> > > >standard Stateless Address Auto-Configuration doesn't=20
> provide extra
> > > >information to help prefix selection. Multi-homing
> > > informaiton option is for
> > > >this purpose.
> > > >
> > > > >
> > > > > With respect to access network related configuration=20
> information,
> > > > > we already have DHCPv6 for that, and more specific=20
> route options
> > > > > for Router Discovery.
> > > >In IPv6, there are two ways for address auto-configuration,
> > > i.e., stateful
> > > >configuration based on DHCPv6, and stateless configuration.
> > > It seems there is
> > > >no standard that says only DHCPv6 can be used in access
> > > network and SAAC
> > > >is forbidden.
> > > >
> > > > >
> > > > > Router Discovery is for prefix and next hop
> > > determination.  Let's not
> > > > > make it complicated for other reasons.
> > > >More information along with prefix information option in RA,
> > > will help
> > > >host select
> > > >the appropriate prefix to form its IPv6 global address and
> > > also select its
> > > >exit
> > > >router. It's not trying to make things complicated. Without
> > > this effort,
> > > >host cannot
> > > >find the appropriate prefix and exit router.
> > >
> > >
> > >
>=20
>=20
>=20

Delivery-date: Fri, 09 Jun 2006 01:00:49 +0000
Date: Fri, 09 Jun 2006 11:00:12 +1000
To: "CTO WEN Haibo" <[email-masked]>, "Greg Daley" <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>

I am saying that I want to you be aware that shim6 is approaching the=20
problem with a particular framework (shim6) in mind.

if your contribution is relevant to that framework then of course this is=20
good - if you head off into alternative multi-6 solutions that have nothing=
=20
to do with shim6, then maybe you should reconsider whether to cc shim6 in=20
your notes.

   Geoff

At 10:46 AM 9/06/2006, CTO WEN Haibo wrote:
>Hi Geoff,
>
>I am wondering the exact meaning of your email. Are you meaning that
>some discussions in this particular thread have less relevance with
>shim6 or the whole thread has less relelevance to shim6?
>
>This document tries to solve the source address selection and exit
>router selection, which is related to the following working item from
>the charter of shim:
>"In addition to the network layer shim solution, the shim6 WG is
>specifically chartered to work on:
>  Solutions for site exit router selection that work when each ISP
>uses ingress filtering, i.e. when the chosen site exit needs to
>be related to the source address chosen by the host. This site
>exit router selection and the associated address selection
>process should work whether or not the peer site supports
>the shim6 protocol."
>
>Best regards,
>
>Haibo
>
> > -----Original Message-----
> > From: Geoff Huston [mailto:[email-masked]]
> > Sent: 2006=E5=B9=B46=E6=9C=889=E6=97=A5 07:00
> > To: CTO WEN Haibo; Greg Daley
> > Cc: Lawrence Zou; [email-masked]
> > Subject: RE: RE: questions about
> > draft-wen-ipv6-rsra-opt-multihoming-00
> >
> >
> > Could please I remind all of you in this particular mail
> > thread that the
> > charter of shim6 is to refine and develop one particular approach to
> > multi-homing, and it is definitely NOT to rehash over the
> > multi6 discussion
> > of "all possible approaches to multihoming".
> >
> > Accordingly, please think for a second about the relevance of your
> > contribution to shim6 before including shim6 in your cc list.
> >
> > thanks,
> >
> >    Geoff
> >
> >
> >
> >
> >
> >
> >
> > At 03:38 PM 7/06/2006, CTO WEN Haibo wrote:
> > >Hi Greg,
> > >
> > >Please see the response below. Thanks.
> > >
> > >Haibo
> > >
> > > > -----Original Message-----
> > > > From: Greg Daley [mailto:[email-masked]]
> > > > Sent: 2006?=C3=AA6??7=C3=A8? 11:15
> > > > To: CTO WEN Haibo
> > > > Cc: Lawrence Zou; [email-masked]; [email-masked]
> > > > Subject: Re: RE: questions about
> > > > draft-wen-ipv6-rsra-opt-multihoming-00
> > > >....
> > > > > The core of this multi-homing information option is
> > that to provide
> > > > > someextra information along with prefix information
> > option to help
> > > > > host do
> > > > > selection, and the host uses the prefix once it finds
> > the matching
> > > > > information in multi-homing information option.
> > > > > ISP name is a sub-option, ISP name is a generalized
> > name, the IPTV
> > > > > service provider can name itself as "IPTV", Internet
> > > > service provider
> > > > > can name itself as "HSI", these names also indicates
> > their service
> > > > > type.Maybe I haven't made this very clear in the draft.
> > Of course,
> > > > > any other option can be also defined under this
> > architecture, for
> > > > > example, what
> > > > > kind of service the isp can provide, the qos parameter, etc.
> > > > > Currently,only a few suboption have been defined.
> > > > >
> > > > > Using this multi-homing option, router can priodically
> > advertises
> > > > > the
> > > > > ISP's ability and related information.
> > > > >
> > > >
> > > > I think it's a much better fit to provide this
> > (changeable) operator
> > > > related information using 802.21 media independent
> > > > information services.
> > >802.21 is developing standards to enable handover and
> > interoperability
> > >between heterogeneous network types including both 802 and non 802
> > >networks. 802.21 is running below IP layer. However, SAAC
> > procedure is
> > >running in IP layer.
> > >You know, in multi-homing site, each router will advertise
> > RA which contains
> > >IPv6 prefix information, and the interface of host will
> > receive all this
> > >RA. The
> > >standard Stateless Address Auto-Configuration doesn't provide extra
> > >information to help prefix selection. Multi-homing
> > informaiton option is for
> > >this purpose.
> > >
> > > >
> > > > With respect to access network related configuration information,
> > > > we already have DHCPv6 for that, and more specific route options
> > > > for Router Discovery.
> > >In IPv6, there are two ways for address auto-configuration,
> > i.e., stateful
> > >configuration based on DHCPv6, and stateless configuration.
> > It seems there is
> > >no standard that says only DHCPv6 can be used in access
> > network and SAAC
> > >is forbidden.
> > >
> > > >
> > > > Router Discovery is for prefix and next hop
> > determination.  Let's not
> > > > make it complicated for other reasons.
> > >More information along with prefix information option in RA,
> > will help
> > >host select
> > >the appropriate prefix to form its IPv6 global address and
> > also select its
> > >exit
> > >router. It's not trying to make things complicated. Without
> > this effort,
> > >host cannot
> > >find the appropriate prefix and exit router.
> >
> >
> >

Delivery-date: Fri, 09 Jun 2006 00:50:15 +0000
content-class: urn:content-classes:message
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Fri, 9 Jun 2006 08:46:29 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "Greg Daley" <[email-masked]>
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>

Delivery-date: Thu, 08 Jun 2006 23:02:11 +0000
Date: Fri, 09 Jun 2006 08:59:53 +1000
To: "CTO WEN Haibo" <[email-masked]>, "Greg Daley" <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>

Could please I remind all of you in this particular mail thread that the=20
charter of shim6 is to refine and develop one particular approach to=20
multi-homing, and it is definitely NOT to rehash over the multi6 discussion=
=20
of "all possible approaches to multihoming".

Accordingly, please think for a second about the relevance of your=20
contribution to shim6 before including shim6 in your cc list.

thanks,

   Geoff

At 03:38 PM 7/06/2006, CTO WEN Haibo wrote:
>Hi Greg,
>
>Please see the response below. Thanks.
>
>Haibo
>
> > -----Original Message-----
> > From: Greg Daley [mailto:[email-masked]]
> > Sent: 2006=C4=EA6=D4=C27=C8=D5 11:15
> > To: CTO WEN Haibo
> > Cc: Lawrence Zou; [email-masked]; [email-masked]
> > Subject: Re: RE: questions about
> > draft-wen-ipv6-rsra-opt-multihoming-00
> >....
> > > The core of this multi-homing information option is that to provide
> > > someextra information along with prefix information option to help
> > > host do
> > > selection, and the host uses the prefix once it finds the matching
> > > information in multi-homing information option.
> > > ISP name is a sub-option, ISP name is a generalized name, the IPTV
> > > service provider can name itself as "IPTV", Internet
> > service provider
> > > can name itself as "HSI", these names also indicates their service
> > > type.Maybe I haven't made this very clear in the draft. Of course,
> > > any other option can be also defined under this architecture, for
> > > example, what
> > > kind of service the isp can provide, the qos parameter, etc.
> > > Currently,only a few suboption have been defined.
> > >
> > > Using this multi-homing option, router can priodically advertises
> > > the
> > > ISP's ability and related information.
> > >
> >
> > I think it's a much better fit to provide this (changeable) operator
> > related information using 802.21 media independent
> > information services.
>802.21 is developing standards to enable handover and interoperability=20
>between heterogeneous network types including both 802 and non 802=20
>networks. 802.21 is running below IP layer. However, SAAC procedure is=20
>running in IP layer.
>You know, in multi-homing site, each router will advertise RA which=
 contains
>IPv6 prefix information, and the interface of host will receive all this=20
>RA. The
>standard Stateless Address Auto-Configuration doesn't provide extra
>information to help prefix selection. Multi-homing informaiton option is=
 for
>this purpose.
>
> >
> > With respect to access network related configuration information,
> > we already have DHCPv6 for that, and more specific route options
> > for Router Discovery.
>In IPv6, there are two ways for address auto-configuration, i.e., stateful
>configuration based on DHCPv6, and stateless configuration. It seems there=
 is
>no standard that says only DHCPv6 can be used in access network and SAAC=20
>is forbidden.
>
> >
> > Router Discovery is for prefix and next hop determination.  Let's not
> > make it complicated for other reasons.
>More information along with prefix information option in RA, will help=20
>host select
>the appropriate prefix to form its IPv6 global address and also select its=
=20
>exit
>router. It's not trying to make things complicated. Without this effort,=20
>host cannot
>find the appropriate prefix and exit router.

Delivery-date: Thu, 08 Jun 2006 00:31:19 +0000
Date: Thu, 08 Jun 2006 09:28:19 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-applicability-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Applicability Statement for the Level 3 
Multihoming Shim Protocol (Shim6)
         Author(s)       : M. Bagnulo, J. Abley
         Filename        : draft-ietf-shim6-applicability-01.txt
         Pages           : 23
         Date            : 2006-6-7

This document discusses the applicability of the Shim6 IPv6 protocol
    element and associated support protocols to provide site multihoming
    capabilities in IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt

Delivery-date: Wed, 07 Jun 2006 06:01:41 +0000
content-class: urn:content-classes:message
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Wed, 7 Jun 2006 14:00:45 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "CTO WEN Haibo" <[email-masked]>, "Greg Daley" <[email-masked]>
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>, <[email-masked]>

In addition, shim6 charter says:=20
...
In addition to the network layer shim solution, the shim6 WG is
specifically chartered to work on:
o Solutions for site exit router selection that work when each ISP
uses ingress filtering, i.e. when the chosen site exit needs to
be related to the source address chosen by the host. This site
exit router selection and the associated address selection
process should work whether or not the peer site supports
the shim6 protocol.
...

Obviously, 802.21 couldn't solve the this kind of issue. Multi-homing =
option can=20
solve the issue.

> -----Original Message-----
> From: CTO WEN Haibo=20
> Sent: 2006=C4=EA6=D4=C27=C8=D5 13:38
> To: 'Greg Daley'
> Cc: Lawrence Zou; [email-masked]; [email-masked]
> Subject: RE: RE: questions about=20
> draft-wen-ipv6-rsra-opt-multihoming-00
>=20
>=20
> Hi Greg,
>=20
> Please see the response below. Thanks.
>=20
> Haibo
>=20
> > -----Original Message-----
> > From: Greg Daley [mailto:[email-masked]]
> > Sent: 2006=C4=EA6=D4=C27=C8=D5 11:15
> > To: CTO WEN Haibo
> > Cc: Lawrence Zou; [email-masked]; [email-masked]
> > Subject: Re: RE: questions about=20
> > draft-wen-ipv6-rsra-opt-multihoming-00
> >....
> > > The core of this multi-homing information option is that=20
> to provide=20
> > > someextra information along with prefix information=20
> option to help=20
> > > host do=20
> > > selection, and the host uses the prefix once it finds the=20
> matching=20
> > > information in multi-homing information option.=20
> > > ISP name is a sub-option, ISP name is a generalized name,=20
> the IPTV=20
> > > service provider can name itself as "IPTV", Internet=20
> > service provider
> > > can name itself as "HSI", these names also indicates=20
> their service=20
> > > type.Maybe I haven't made this very clear in the draft.=20
> Of course,=20
> > > any other option can be also defined under this architecture, for=20
> > > example, what=20
> > > kind of service the isp can provide, the qos parameter, etc.=20
> > > Currently,only a few suboption have been defined.
> > >=20
> > > Using this multi-homing option, router can priodically advertises=20
> > > the=20
> > > ISP's ability and related information.
> > >
> >=20
> > I think it's a much better fit to provide this (changeable) operator
> > related information using 802.21 media independent=20
> > information services.
> 802.21 is developing standards to enable handover and=20
> interoperability between heterogeneous network types=20
> including both 802 and non 802 networks. 802.21 is running=20
> below IP layer. However, SAAC procedure is running in IP layer.
> You know, in multi-homing site, each router will advertise RA=20
> which contains
> IPv6 prefix information, and the interface of host will=20
> receive all this RA. The=20
> standard Stateless Address Auto-Configuration doesn't provide extra=20
> information to help prefix selection. Multi-homing=20
> informaiton option is for
> this purpose.
>=20
> >=20
> > With respect to access network related configuration information,
> > we already have DHCPv6 for that, and more specific route options
> > for Router Discovery.
> In IPv6, there are two ways for address auto-configuration,=20
> i.e., stateful
> configuration based on DHCPv6, and stateless configuration.=20
> It seems there is
> no standard that says only DHCPv6 can be used in access=20
> network and SAAC is forbidden.
>=20
> >=20
> > Router Discovery is for prefix and next hop determination. =20
> Let's not
> > make it complicated for other reasons.
> More information along with prefix information option in RA,=20
> will help host select
> the appropriate prefix to form its IPv6 global address and=20
> also select its exit
> router. It's not trying to make things complicated. Without=20
> this effort, host cannot
> find the appropriate prefix and exit router.
>=20

Delivery-date: Wed, 07 Jun 2006 05:40:19 +0000
content-class: urn:content-classes:message
Subject: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Wed, 7 Jun 2006 13:38:01 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Greg Daley" <[email-masked]>
Cc: "Lawrence Zou" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Greg,

Please see the response below. Thanks.

Haibo

> -----Original Message-----
> From: Greg Daley [mailto:[email-masked]]
> Sent: 2006=C4=EA6=D4=C27=C8=D5 11:15
> To: CTO WEN Haibo
> Cc: Lawrence Zou; [email-masked]; [email-masked]
> Subject: Re: RE: questions about=20
> draft-wen-ipv6-rsra-opt-multihoming-00
>....
> > The core of this multi-homing information option is that to provide=20
> > someextra information along with prefix information option to help=20
> > host do=20
> > selection, and the host uses the prefix once it finds the matching=20
> > information in multi-homing information option.=20
> > ISP name is a sub-option, ISP name is a generalized name, the IPTV=20
> > service provider can name itself as "IPTV", Internet=20
> service provider
> > can name itself as "HSI", these names also indicates their service=20
> > type.Maybe I haven't made this very clear in the draft. Of course,=20
> > any other option can be also defined under this architecture, for=20
> > example, what=20
> > kind of service the isp can provide, the qos parameter, etc.=20
> > Currently,only a few suboption have been defined.
> >=20
> > Using this multi-homing option, router can priodically advertises=20
> > the=20
> > ISP's ability and related information.
> >
>=20
> I think it's a much better fit to provide this (changeable) operator
> related information using 802.21 media independent=20
> information services.
802.21 is developing standards to enable handover and interoperability =
between heterogeneous network types including both 802 and non 802 =
networks. 802.21 is running below IP layer. However, SAAC procedure is =
running in IP layer.
You know, in multi-homing site, each router will advertise RA which =
contains
IPv6 prefix information, and the interface of host will receive all this =
RA. The=20
standard Stateless Address Auto-Configuration doesn't provide extra=20
information to help prefix selection. Multi-homing informaiton option is =
for
this purpose.

>=20
> With respect to access network related configuration information,
> we already have DHCPv6 for that, and more specific route options
> for Router Discovery.
In IPv6, there are two ways for address auto-configuration, i.e., =
stateful
configuration based on DHCPv6, and stateless configuration. It seems =
there is
no standard that says only DHCPv6 can be used in access network and SAAC =
is forbidden.

>=20
> Router Discovery is for prefix and next hop determination.  Let's not
> make it complicated for other reasons.
More information along with prefix information option in RA, will help =
host select
the appropriate prefix to form its IPv6 global address and also select =
its exit
router. It's not trying to make things complicated. Without this effort, =
host cannot
find the appropriate prefix and exit router.

Delivery-date: Wed, 07 Jun 2006 03:16:13 +0000
Date: Tue, 06 Jun 2006 23:15:29 -0400
From: Greg Daley <[email-masked]>
Subject: Re: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
To: CTO WEN Haibo <[email-masked]>
Cc: Lawrence Zou <[email-masked]>, [email-masked], [email-masked]

Hi Wen, 

----- Original Message -----
From: CTO WEN Haibo <[email-masked]>
Date: Tuesday, June 6, 2006 9:34 pm
Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
To: Lawrence Zou <[email-masked]>
Cc: [email-masked], [email-masked]

> Please see below.
> 
> 
> > -----Original Message-----
> > From: Lawrence Zou [mailto:[email-masked]]
> > Sent: 2006?6?6? 17:33
> > To: CTO WEN Haibo
> > Cc: [email-masked]; [email-masked]
> 
> > >In current IPv6 multihoming site, each hosts in this site can 
> > >have multiple prefixes from different exit routers. It cannot 
> > >identify which ISP assignes 
> > >the exact prefix, because there is no extra information in 
> > >prefix information option.
> > >
> > >The multi-homing information defined in this draft is used 
> > >along with prefix information option. It will provide extra 
> > >information for host to do selection. Host only selects the 
> > >prefix from the desired ISP to form its IPv6 address, of 
> > >course, the corresponding exit router will be cached. Other 
> > >prefixes from other routers will not be used to form IP 
> > >address. For example, STB may only want services from IPTV 
> > >service provider. Other prefixes from other service providers 
> > >are useless for itself.
> > 
> > yes,i think you point out the most important thing:the host only 
> > form IP adress it will use it .
> > so i guess that:
> > 1)ISP1 and ISP2 send RA with prefix information and multi-homing
> > information.
> > 2)if host can decide whitch ISP it will select,for example ,it 
> select> ISP1,the host will form address with
> >  the prefix in the RA of ISP1 and ignore  the RA of ISP2.
> > 
> > >
> > >Host knows which ISP it will got its service, and it also 
> > >knows its exit router is the edge router of the desired ISP. 
> > >But it doesn't know the network topology, it doesn't know the 
> > >exact exit router either, unless multi-homing informaiton 
> > >option is used along the prefix information option.
> > 
> > i do not agree with this point of "Host knows which ISP it will 
> got its
> > service" in the scenario of  stateless address auto-configure,in 
> the SAAC,
> > we should assume that No manual configuration 
> > of individual machines  before connecting them to the network, 
> but if
> > you do not do some manual configuration,
> > how can you know which ISP the host will got its service?One 
> available> method the host can do this is it ask "who
> > can provide the service of......?" and if someone  anwer it 
> > "i can do it ",then the host select this ISP.
> 
> The core of this multi-homing information option is that to provide 
> someextra information along with prefix information option to help 
> host do 
> selection, and the host uses the prefix once it finds the matching 
> information in multi-homing information option. 
> ISP name is a sub-option, ISP name is a generalized name, the IPTV 
> service provider can name itself as "IPTV", Internet service provider
> can name itself as "HSI", these names also indicates their service 
> type.Maybe I haven't made this very clear in the draft. Of course, 
> any other option can be also defined under this architecture, for 
> example, what 
> kind of service the isp can provide, the qos parameter, etc. 
> Currently,only a few suboption have been defined.
> 
> Using this multi-homing option, router can priodically advertises 
> the 
> ISP's ability and related information.
>

I think it's a much better fit to provide this (changeable) operator
related information using 802.21 media independent information services.

With respect to access network related configuration information,
we already have DHCPv6 for that, and more specific route options
for Router Discovery.

Router Discovery is for prefix and next hop determination.  Let's not
make it complicated for other reasons.

Greg

Delivery-date: Wed, 07 Jun 2006 01:32:30 +0000
content-class: urn:content-classes:message
Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Wed, 7 Jun 2006 09:31:13 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Lawrence Zou" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Please see below.

> -----Original Message-----
> From: Lawrence Zou [mailto:[email-masked]]
> Sent: 2006=C4=EA6=D4=C26=C8=D5 17:33
> To: CTO WEN Haibo
> Cc: [email-masked]; [email-masked]

> >In current IPv6 multihoming site, each hosts in this site can=20
> >have multiple prefixes from different exit routers. It cannot=20
> >identify which ISP assignes=20
> >the exact prefix, because there is no extra information in=20
> >prefix information option.
> >
> >The multi-homing information defined in this draft is used=20
> >along with prefix information option. It will provide extra=20
> >information for host to do selection. Host only selects the=20
> >prefix from the desired ISP to form its IPv6 address, of=20
> >course, the corresponding exit router will be cached. Other=20
> >prefixes from other routers will not be used to form IP=20
> >address. For example, STB may only want services from IPTV=20
> >service provider. Other prefixes from other service providers=20
> >are useless for itself.
>=20
> yes,i think you point out the most important thing:the host only=20
> form IP adress it will use it .
> so i guess that:
> 1)ISP1 and ISP2 send RA with prefix information and multi-homing
> information.
> 2)if host can decide whitch ISP it will select,for example ,it select
> ISP1,the host will form address with
>  the prefix in the RA of ISP1 and ignore  the RA of ISP2.
>=20
> >
> >Host knows which ISP it will got its service, and it also=20
> >knows its exit router is the edge router of the desired ISP.=20
> >But it doesn't know the network topology, it doesn't know the=20
> >exact exit router either, unless multi-homing informaiton=20
> >option is used along the prefix information option.
>=20
> i do not agree with this point of "Host knows which ISP it will got =
its
> service" in the scenario of  stateless address auto-configure,in the =
SAAC,
> we should assume that No manual configuration=20
> of individual machines  before connecting them to the network, but if
> you do not do some manual configuration,
> how can you know which ISP the host will got its service?One available
> method the host can do this is it ask "who
> can provide the service of......?" and if someone  anwer it=20
> "i can do it ",then the host select this ISP.

The core of this multi-homing information option is that to provide some
extra information along with prefix information option to help host do=20
selection, and the host uses the prefix once it finds the matching=20
information in multi-homing information option.=20
ISP name is a sub-option, ISP name is a generalized name, the IPTV=20
service provider can name itself as "IPTV", Internet service provider
can name itself as "HSI", these names also indicates their service type.
Maybe I haven't made this very clear in the draft. Of course, any other =
option can be also defined under this architecture, for example, what=20
kind of service the isp can provide, the qos parameter, etc. Currently,
only a few suboption have been defined.

Using this multi-homing option, router can priodically advertises the=20
ISP's ability and related information.

> >
> >Best regards,
> >
> >Haibo
> >
> >
> >> -----Original Message-----
> >> From: Lawrence Zou [mailto:[email-masked]]
> >> Sent: 2006=C4=EA6=D4=C26=C8=D5 15:09
> >> To: CTO WEN Haibo
> >> Cc: [email-masked]; [email-masked]
> >> Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
> >>=20
> >>=20
> >> sorry,I am confused by your draft.
> >>=20
> >> in section 1 you mentioned the purpose of your idear is =20
> >"How to help=20
> >> host implement
> >>    exit router selection and the associated prefix or address
> >> selection
> >> "
> >>=20
> >> in my understand ,
> >> your prblem is the host have got several prefix or addresses from=20
> >> different routers,when the host have some data to send to a=20
> >> destination, it must choose a source address and a exit router. is=20
> >> that true?
> >>=20
> >> for this purpose ,the host send RS with the multihome-option
> >> that carry
> >> some information such as ISP name ,then  the corresponding=20
> >exit router
> >> response it  wiht  RA.
> >>=20
> >> but  I think if the host have know which ISP it will got it's=20
> >> service(explicit by ISP name),that also mean the host have already=20
> >> selected one exit router and the corresponding source address.
> >>=20
> >> maybe i have misunderstand the procedure.can you explain it more=20
> >> explicit ?
> >>=20
> >> thanks
> >>=20
> >> Best regards
> >>=20
> >> Lawrence
> >>=20
> >> >-----Original Message-----
> >> >From: CTO WEN Haibo [mailto:[email-masked]]
> >> >Sent: Tuesday, June 06, 2006 1:44 PM
> >> >To: Lawrence Zou
> >> >Cc: [email-masked]; [email-masked]
> >> >Subject: RE: questions about=20
> draft-wen-ipv6-rsra-opt-multihoming-00
> >> >
> >> >
> >> >hi Lawrence,
> >> >
> >> >I'm glad to receive your comments.
> >> >
> >> >I can explain to you one by one.
> >> >
> >> >1. The secnarios in the draft are using the ISP name
> >> >sub-option. It does not=20
> >> >mean that it's a "MUST" sub-option in the multi-homing=20
> >> >information option for=20
> >> >RS message (and other sub-option can be used if needed). Of=20
> >> >course, if we want to solve the problem described in the=20
> >> >charter of shim6 w.g., it is a "MUST" sub-option for RA=20
> >> >message. Without this information along with the Prefix=20
> >> >Information option, host doesn't know how to choose the=20
> >> >appropriate prefix and=20
> >> >the associated exit router.=20
> >> >I think multi-homing environment doesn't mean that some hosts=20
> >> >in a multi- home site just in the VLAN connected to a=20
> >> >specified ISP. All the hosts in the=20
> >> >multihome site have been connected to all the exit routers=20
> >> >that belongs to=20
> >> >different ISP. That is, the host can obtain all the periodical=20
> >> >RA messages from different routers. Our goal is to solve=20
> >> >prefix selection and exit router selection in this environment.
> >> >
> >> >2. First, that's just an example of how to use multi-homing
> >> >option in access network. It can also be used in LAN with=20
> >> >multiple exit routers. The layer2 access node I mean in this=20
> >> >example is not just a pure layer2 devices. It can snoop some=20
> >> >special layer3 packets, such as RS/RA messages, then it can=20
> >> >forward the RS to the correct router without flooding it to=20
> >> >other parts of=20
> >> >access netework.=20
> >> >If the access node doesn't have this ability, RS can be sent=20
> >> >to all routers, only the corresponding will respond this RS=20
> >> >message. This will not add any bad=20
> >> >impact.
> >> >
> >> >Thanks.
> >> >
> >> >Best regards,
> >> >
> >> >Haibo
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Lawrence Zou [mailto:[email-masked]]
> >> >> Sent: 2006=C4=EA6=D4=C26=C8=D5 12:04
> >> >> To: CTO WEN Haibo
> >> >> Cc: [email-masked]
> >> >> Subject: questions about draft-wen-ipv6-rsra-opt-multihoming-00
> >> >>=20
> >> >>=20
> >> >> hi,wen:
> >> >>=20
> >> >>      i have read you draft.  Although there are some strong
> >> >technical
> >> >> points in this document,  i still think there are some=20
> >big problem:
> >> >>=20
> >> >> 1. I noticed  that in all 3 Scenarios, the RS message must
> >> >include ISP
> >> >> name sub-option,so,is it a "MUST"  sub-optinon that be
> >> >include in the
> >> >> Multi-homing Information option? if it is true,what will it
> >> >happen if
> >> >> the host don't know the name of the ISP? I think in the
> >> Scenarios of
> >> >> stateless addres autoconfigue, it is not necessary for
> >> host to know
> >> >> the topology of the network and the name of the ISP.
> >> >> in your draft ,all hosts know clearly which ISP they belong
> >> >> to ,I think
> >> >> we can distinguish them using some kinds of  VLAN techonoly.
> >> >>=20
> >> >> 2.In Scenario 3,you mention the equipment of "layer2 CPE
> >> >".so what the
> >> >> difference is that with "layer3 CPE "? In my understand
> >> ,the layer2
> >> >> CPE is a layer2 equipmnet ,so in the section 3.3
> >> >>    Step (b) : Base on the information in Multi-homing
> >> >> Information option
> >> >>               , layer 2 access node can forward this RS to=20
> >> >the correct
> >> >>               edge router of the desired ISP without sending
> >> >> it to the=20
> >> >>               router that will not respond this RS.=09
> >> >>=20
> >> >>  can layer2 equipment do this kind of thing?=09
> >> >>  =20
> >> >>=20
> >> >>=20
> >> >>=20
> >> >
> >>=20
> >>=20
> >>=20
> >
>=20
>=20
>=20

Delivery-date: Tue, 06 Jun 2006 08:55:07 +0000
content-class: urn:content-classes:message
Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Tue, 6 Jun 2006 16:54:05 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Lawrence Zou" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Lawrence,

In current IPv6 multihoming site, each hosts in this site can have =
multiple
prefixes from different exit routers. It cannot identify which ISP =
assignes=20
the exact prefix, because there is no extra information in prefix =
information
option.

The multi-homing information defined in this draft is used along with =
prefix
information option. It will provide extra information for host to do =
selection.
Host only selects the prefix from the desired ISP to form its IPv6 =
address,
of course, the corresponding exit router will be cached. Other prefixes =
from
other routers will not be used to form IP address. For example, STB may
only want services from IPTV service provider. Other prefixes from other
service providers are useless for itself.

Host knows which ISP it will got its service, and it also knows its exit =
router
is the edge router of the desired ISP. But it doesn't know the network =
topology,
it doesn't know the exact exit router either, unless multi-homing =
informaiton
option is used along the prefix information option.

Best regards,

Haibo

> -----Original Message-----
> From: Lawrence Zou [mailto:[email-masked]]
> Sent: 2006=C4=EA6=D4=C26=C8=D5 15:09
> To: CTO WEN Haibo
> Cc: [email-masked]; [email-masked]
> Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>=20
>=20
> sorry,I am confused by your draft.
>=20
> in section 1 you mentioned the purpose of your idear is  "How to help
> host implement=20
>    exit router selection and the associated prefix or address=20
> selection
> "
>=20
> in my understand ,
> your prblem is the host have got several prefix or addresses from
> different routers,when the host have some data to send to a=20
> destination,
> it must choose a source address and a exit router. is that true?
>=20
> for this purpose ,the host send RS with the multihome-option=20
> that carry
> some information such as ISP name ,then  the corresponding exit router
> response it  wiht  RA.
>=20
> but  I think if the host have know which ISP it will got it's
> service(explicit by ISP name),that also mean the host have already
> selected one exit router and the corresponding source address.
>=20
> maybe i have misunderstand the procedure.can you explain it more
> explicit ?=20
>=20
> thanks=20
>=20
> Best regards
>=20
> Lawrence
>=20
> >-----Original Message-----
> >From: CTO WEN Haibo [mailto:[email-masked]]=20
> >Sent: Tuesday, June 06, 2006 1:44 PM
> >To: Lawrence Zou
> >Cc: [email-masked]; [email-masked]
> >Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
> >
> >
> >hi Lawrence,
> >
> >I'm glad to receive your comments.
> >
> >I can explain to you one by one.
> >
> >1. The secnarios in the draft are using the ISP name=20
> >sub-option. It does not=20
> >mean that it's a "MUST" sub-option in the multi-homing=20
> >information option for=20
> >RS message (and other sub-option can be used if needed). Of=20
> >course, if we want to solve the problem described in the=20
> >charter of shim6 w.g., it is a "MUST" sub-option for RA=20
> >message. Without this information along with the Prefix=20
> >Information option, host doesn't know how to choose the=20
> >appropriate prefix and=20
> >the associated exit router.=20
> >I think multi-homing environment doesn't mean that some hosts=20
> >in a multi- home site just in the VLAN connected to a=20
> >specified ISP. All the hosts in the=20
> >multihome site have been connected to all the exit routers=20
> >that belongs to=20
> >different ISP. That is, the host can obtain all the periodical=20
> >RA messages from different routers. Our goal is to solve=20
> >prefix selection and exit router selection in this environment.
> >
> >2. First, that's just an example of how to use multi-homing=20
> >option in access network. It can also be used in LAN with=20
> >multiple exit routers. The layer2 access node I mean in this=20
> >example is not just a pure layer2 devices. It can snoop some=20
> >special layer3 packets, such as RS/RA messages, then it can=20
> >forward the RS to the correct router without flooding it to=20
> >other parts of=20
> >access netework.=20
> >If the access node doesn't have this ability, RS can be sent=20
> >to all routers, only the corresponding will respond this RS=20
> >message. This will not add any bad=20
> >impact.
> >
> >Thanks.
> >
> >Best regards,
> >
> >Haibo
> >
> >
> >
> >> -----Original Message-----
> >> From: Lawrence Zou [mailto:[email-masked]]
> >> Sent: 2006=C4=EA6=D4=C26=C8=D5 12:04
> >> To: CTO WEN Haibo
> >> Cc: [email-masked]
> >> Subject: questions about draft-wen-ipv6-rsra-opt-multihoming-00
> >>=20
> >>=20
> >> hi,wen:
> >>=20
> >>      i have read you draft.  Although there are some strong=20
> >technical=20
> >> points in this document,  i still think there are some big problem:
> >>=20
> >> 1. I noticed  that in all 3 Scenarios, the RS message must=20
> >include ISP=20
> >> name sub-option,so,is it a "MUST"  sub-optinon that be=20
> >include in the=20
> >> Multi-homing Information option? if it is true,what will it=20
> >happen if=20
> >> the host don't know the name of the ISP? I think in the=20
> Scenarios of=20
> >> stateless addres autoconfigue, it is not necessary for=20
> host to know=20
> >> the topology of the network and the name of the ISP.
> >> in your draft ,all hosts know clearly which ISP they belong=20
> >> to ,I think
> >> we can distinguish them using some kinds of  VLAN techonoly.
> >>=20
> >> 2.In Scenario 3,you mention the equipment of "layer2 CPE=20
> >".so what the=20
> >> difference is that with "layer3 CPE "? In my understand=20
> ,the layer2=20
> >> CPE is a layer2 equipmnet ,so in the section 3.3
> >>    Step (b) : Base on the information in Multi-homing=20
> >> Information option
> >>               , layer 2 access node can forward this RS to=20
> >the correct
> >>               edge router of the desired ISP without sending=20
> >> it to the=20
> >>               router that will not respond this RS.=09
> >>=20
> >>  can layer2 equipment do this kind of thing?=09
> >>  =20
> >>=20
> >>=20
> >>=20
> >
>=20
>=20
>=20

Delivery-date: Tue, 06 Jun 2006 05:45:16 +0000
content-class: urn:content-classes:message
Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
Date: Tue, 6 Jun 2006 13:44:18 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: "Lawrence Zou" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi Lawrence,

I'm glad to receive your comments.

I can explain to you one by one.

1. The secnarios in the draft are using the ISP name sub-option. It does =
not=20
mean that it's a "MUST" sub-option in the multi-homing information =
option for=20
RS message (and other sub-option can be used if needed). Of course, if =
we
want to solve the problem described in the charter of shim6 w.g., it is =
a "MUST"
sub-option for RA message. Without this information along with the =
Prefix=20
Information option, host doesn't know how to choose the appropriate =
prefix and=20
the associated exit router.=20
I think multi-homing environment doesn't mean that some hosts in a =
multi-
home site just in the VLAN connected to a specified ISP. All the hosts =
in the=20
multihome site have been connected to all the exit routers that belongs =
to=20
different ISP. That is, the host can obtain all the periodical RA =
messages from
different routers. Our goal is to solve prefix selection and exit router =
selection in
this environment.

2. First, that's just an example of how to use multi-homing option in =
access
network. It can also be used in LAN with multiple exit routers.
The layer2 access node I mean in this example is not just a pure layer2 =
devices.
It can snoop some special layer3 packets, such as RS/RA messages, then =
it
can forward the RS to the correct router without flooding it to other =
parts of=20
access netework.=20
If the access node doesn't have this ability, RS can be sent to all =
routers, only
the corresponding will respond this RS message. This will not add any =
bad=20
impact.

Thanks.

Best regards,

Haibo

> -----Original Message-----
> From: Lawrence Zou [mailto:[email-masked]]
> Sent: 2006=C4=EA6=D4=C26=C8=D5 12:04
> To: CTO WEN Haibo
> Cc: [email-masked]
> Subject: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>=20
>=20
> hi,wen:
>=20
>      i have read you draft.  Although there are some strong technical
> points in this document,  i still think there are some big problem:
>=20
> 1. I noticed  that in all 3 Scenarios, the RS message must include ISP
> name sub-option,so,is it a "MUST"  sub-optinon that be include in the=20
> Multi-homing Information option? if it is true,what will it happen if
> the host don't know the name of the ISP? I think in the Scenarios of
> stateless=20
> addres autoconfigue, it is not necessary for host to know the topology
> of the network and the name of the ISP.
> in your draft ,all hosts know clearly which ISP they belong=20
> to ,I think
> we can distinguish them using some kinds of  VLAN techonoly.
>=20
> 2.In Scenario 3,you mention the equipment of "layer2 CPE ".so what the
> difference is that with "layer3 CPE "? In my understand ,the=20
> layer2 CPE=20
> is a layer2 equipmnet ,so in the section 3.3=20
>    Step (b) : Base on the information in Multi-homing=20
> Information option
>               , layer 2 access node can forward this RS to the correct
>               edge router of the desired ISP without sending=20
> it to the=20
>               router that will not respond this RS.=09
>=20
>  can layer2 equipment do this kind of thing?=09
>  =20
>=20
>=20
>=20

Delivery-date: Tue, 06 Jun 2006 01:09:13 +0000
content-class: urn:content-classes:message
Subject: I-D ACTION:draft-wen-ipv6-rsra-opt-multihoming-00.txt 
Date: Tue, 6 Jun 2006 09:07:06 +0800
From: "CTO WEN Haibo" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Dear all,

Here is a new draft which defines a new option named Multi-homing =
Informaton
option for RS/RA message. This can be used as solutions for site exit =
router=20
selection and the associated address selection when each ISP uses =
ingress
filtering.

Hope the experts here could comment on this draft. Thank you in advance.

Best regards,

Haibo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 2006?4?5? 03:50
To: [email-masked]
Subject: I-D ACTION:draft-wen-ipv6-rsra-opt-multihoming-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

	Title		: Multi-homing Information option for Stateless Address =
Auto-Configuration
	Author(s)	: H. Wen
	Filename	: draft-wen-ipv6-rsra-opt-multihoming-00.txt
	Pages		: 14
	Date		: 2006-4-4
=09
   This document makes an extension to the standard RS/RA messages for
   IPv6 network to solve some problems occurring in multi-homing
   evironment. A new options, that is, Multi-homing Information option=20
   is defined to help host do network selection and prefix selection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wen-ipv6-rsra-opt-multihoming-0=
0.txt