Subject: Re: Second shim
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Date: Mon, 31 Oct 2005 01:29:52 -0800

Thinking about a second shim to handle connection establishment, I've 
come up with code (not running yet ;-) to do a
	int connect_by_name(char *hostname, int port);
that can be implemented entirely as a library (using non-blocking 
connect() calls). It returns a socket file descriptor.

One could try to apply this technique to make connect() do the same 
thing, in coordination with getaddrinfo(), but that is more complex for 
several reasons:
1. Need the coordination between getaddrinfo() and connect() somewhere - 
need to store the alternate IP addresses so that connect() can find them.
2. Need to handle cases when the socket passed in to connect has already 
been bound, or has had some options set.
3. It isn't transparent to the application; the application might pass 
IP address B1 to the connect() call, but the connection is in fact made 
to IP address B2. Thus applications might fail due to this. The 
application needs to use getpeername() to find out the actual address to 
which it has connected.

For by connect_by_name() and the connect() hackery, this only applies to 
TCP; can't make it apply to UDP since UDP doesn't have a notion of "I 
succeeded using this IP address".

    Erik

Delivery-date: Mon, 31 Oct 2005 16:56:34 +0000
Date: Mon, 31 Oct 2005 01:22:17 -0800
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Simplified REAP description

Iljitsch van Beijnum wrote:

>> If it is an "event reception report", it indicates that we can  
>> terminate the
>> explore phase.
>> If the host has not yet sent a "iseeyou=yes" event report, it needs to
>> send one in response to this packet.
> 
> 
> Now suppose:
> 
> A1 ----> B1  (data)
> A1 <---- B1  (data)
> A1 ---|  B1  (data, failure)
>              (timeout)
> A1 <---- B1  (icu=0)
> A1 ---|  B1  (icu=1)
> A2 <---- B1  (icu=1, B hasn't timed out from the last message by A)
> A1 ----> B2  (icu=1)
> 
> Both now think that the other end can see them but this isn't  
> necessarily true because the icu=1 doesn't necessarily apply to the  
> last packet sent by the other side. For instance:

Which is why the REAP Probe contains the sequence numbers. Tells the 
receiver which REAP Probe the other end has received.

> A1 ----> B1  (data)
> A1 <---- B1  (data)
> A1 ---|  B1  (data, failure)
>              (timeout)
> A1 <---- B1  (icu=0)
> A1 ---|  B1  (icu=1)
> A2 <---- B1  (icu=0)
> A1 ----> B2  (icu=1)
> A2  |--- B1  (icu=1, random packet loss on otherwise working link)
> A2 ---|  B2  (icu=1, ingress filtering)
> A2 <---- B2  (icu=1)
> 
> A will now think that A2->B2 works, which isn't true.

Same comment as above.

I can't see a case where icu=1 (together with the REAP probe sequence 
numbers that have been received) would not indicate that the sender has 
seen at least one of the REAP probe packets.

(But having the FBD keepalives be separate messages would make it easier 
to think about all the cases.)

    Erik

Delivery-date: Mon, 31 Oct 2005 16:05:33 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "shim6" <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection
Date: Mon, 31 Oct 2005 10:03:49 -0600

Hi, Bernard,

Thank you for providing these comments (and thanks, Jari, for forwarding 
them).

A couple of thoughts inline,

Spencer

>
> Here are some comments from Bernard Aboba. These relate to
> the failure and reachability detection and perhaps also more
> generally the division of work between the shim and
> other protocol layers. I wasn't quite sure what to say
> in response, so with Bernard's permission, I'm posting
> the comments here:
>
> ----
>
> I read the SHIM6 failure detection documents, and had some comments
> relating to the time scale of failure detection.  I think there are some
> issues with respect to "conservation of packets" that are worth exploring.
>
>
> Section 5
>
>    Also, it
>    would be unfortunate if both the IP layer and transport/application
>    layer took action for the same problem, for instance by switching to
>    a new address at the IP layer and throttling back due to "congestion"
>    at the transport layer.
>
> This is not necessarily undesirable.  If the path over which a TCP
> connection
> travels changes, the transport parameters may have become invalid.  In
> such
> a situation, studies have shown that re-estimation actually may improve
> performance, as compared to continuing to operate with potentially invalid
> values.

Two points here - first, I am interested in pointers to these studies, 
because I'd like to understand the issues a lot better than I do, and, 
second, even if this is true, it's starting to feel like we're moving at 
least some transport functionality (liveness detection, for instance) into 
the network layer, which (as you point out) lives in a different timescale 
(theoretically we give link layers time to react, and then we give routing 
time to react, and THEN TCP starts thinking about retransmission timeouts, 
ignoring fast retransmit for now).

This concerns me, because the TRIGTRAN discussions proved fairly intractable 
given a first-hop path change, and TCP is still TCP, so I'm not sure why 
SHIM6 will end up at a different place if we try to pass a lot of clues back 
and forth between TCP and IP. The only signal both ends of a TCP connection 
share is loss, which both ends have to track anyway, so we got a lot of 
non-interest in adding more stuff that TCP implementations had to track in 
addition to loss.

> I would therefore argue that the important issue is not action
> in multiple layers, but rather the avoidance of race conditions;  a
> well-defined communication mechanism between the IP and
> transport/application
> layer can help with this.

I agree here, with the caveat that it's challenging to know that we've 
avoided race conditions when they involve at least one protocol with 
adaptive timers..

>    But it is less clear which protocol(s) should discover end-to-end
>    connectivity problems or recover from them.  One answer is that this
>    is clearly within the domain of multihoming protocol.  By performing
>    testing and failure detection of the used path and switching to a new
>    path if necessary, the transport and application protocols can work
>    unchanged.
>
> I am not clear that the "multi-homing protocol" necessarily has the right
> information to do testing and failure detection correctly.
>
> For example, it does not make sense to diagnose a "connectivity problem"
> on a time scale less than RTO.  Yet only the tranport layer typically
> possesses the RTO estimate.

Yes, exactly.

I can only add that I'm not sure where we are on one-way data streams (where 
the receiver does not send ACKs, or sends them very infrequently). It's hard 
for the IP layer to know whether "silence is OK", and if the 
transport/application layer has to provide this information, I'm not sure 
what value SHIM6 is adding.

We can explicitly say that we don't believe such things exist in the real 
world, but it would be good if SHIM6 did not prevent these applications from 
working if it DOES encounter them on live networks.

> Similarly, if the cause of the connectivity loss is a route flap, then
> only the routing layer might have knowledge of the loss of the route, and
> only if it is participating in the routing mesh.  For example, in adhoc
> networks, missing routes are a frequent contributor to packet loss, so
> that integration of the routing and transport layers is required to be
> able to respond  appropriately.
>
> On a global scale, BGP route flaps can last for a few seconds (though
> rarely longer than 30 seconds), suggesting a minimum time scale on which
> "connectivity loss" can be detected (this is why RFC 3539 timers are set
> at a minimum of 6 seconds, but at a default value of 30 seconds). 

Delivery-date: Mon, 31 Oct 2005 14:32:05 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Date: Mon, 31 Oct 2005 15:32:00 +0100
To: Iljitsch van Beijnum <[email-masked]>

El 31/10/2005, a las 13:02, Iljitsch van Beijnum escribi=F3:

> On 31-okt-2005, at 11:54, marcelo bagnulo braun wrote:
>
>>> Is there any good reason why this retry/source-select state can not=20=

>>> be kept inside the shim6 layer? The remit of shim6 is after all to=20=

>>> handle this stuff transparently.
>
>> Because:
>> First, you cannot assume that all hosts support the shim
>
> Well, if we can provide unmodified applications on shim-capable hosts=20=

> with this functionality that would be very good. There are several=20
> advantages to using the shim here, including better opportunities for=20=

> security and traffic engineering,

agree, but this is a different problem imho and different mechanisms=20
can do this.

I mean, because of deployment times and motivations we cannot assume a=20=

universal deployment of the shim anytime soon.
So, taking this into account, it would be good if we could provide the=20=

mechanisms so that a multihomed host that implements them can establish=20=

a new communication with a non shim enabled host.
The rationale for this is that non-multihomed host has little=20
motivation to implement mechanisms that provide better multihoming=20
support, while, multihomed hosts do have a motivation for adopting=20
mechanisms that allows them to improve their communications.
Having a rfc3484bis that allows to establish new communications after=20
an outage that only requires modifications to multihomed hosts make=20
sense from a deployment p.o.v

OTOH, i think that it also makes a lot of sense to have the capability=20=

that you are suggesting, that would allow an unmodified application=20
running in a shim capable hosts to establish a communication after an=20
outage. But i see these as two different mechanisms that work under=20
different scenarios, and i think it make sense to work on both of them.=20=

(probably we also want to work on the case of a shim aware app running=20=

in a shim host too)

> although it would of course be nice if we could have the same=20
> functionality when one host doesn't support the shim.
>
>> Second, even if they do, such approach would imply that the shim=20
>> negotiation is made upfront i.e. that the shim session is established=20=

>> before the communication starts, which is completelly opposed to=20
>> current deferred context approach that is being followed throughout=20=

>> the shim6 design
>
> We don't have to change our current thinking for sessions where the=20
> initially chosen ULIDs are reachable: only when those turn out=20
> unreachable, we need to do additional work.
>

right, this is similar to Paul's comment and i agree

> The main problems here are detecting that the initial ULID/locator=20
> pair doesn't work

well, if you are using a shim signaling packet exchenge, this probably=20=

can be done using the shim context establishment exchenge, depends on=20
whether you want to achieve...

>  before we have any shim state we can use, and finding additional=20
> locators. HBA should allow us to make certain that these locators=20
> belong to the initially chosen ULID. However, it's possible that=20
> people publish AAAA records for different hosts that provide the same=20=

> service so the HBA check would presumably not work then. So either we=20=

> need something independent of AAAA records, or limit ourselves to the=20=

> case where the AAAA addresses are part of the same HBA set.
>
> Still, I'm not too worried about this, finding locators can be=20
> improved later.
>
> BTW, being able to do the shim before communication starts also=20
> provides a good path towards something we'll want in the future:=20
> disjunct ULID/locator sets. Having a mechanism in place that allows=20
> using non-IPv6 ULIDs in the future would also help here.
>

right. as i said, i think that allowing shim to deal with failures at=20
initial contact and rfc3484bis complement each other, since they are=20
aimed to different scenarios

>> So, we need to deal with the following situation:
>
>>              /-- ( A ) ---(      )
>>    X (site X)             ( IPv6 ) ---(C)---(site Y)Y
>>              \-- ( B ) ---(      )
>
>> Where, host X supports multihoming features, something like an=20
>> rfc3484 bis and event the shim if you want, but host Y does NOT=20
>> support the shim.
>> Suppose now that ISPA fails, what do you do?
>
> Obviously not repair the failure using the shim...
>
> So either use the "second shim" approach or hope that the application=20=

> does the right thing.
>
>> If you don't let X use the shim, then how does it selects the source=20=

>> address?
>> If you use current rfc 3484 you are stuck in a single source address,
>
> In my experience hosts try different source addresses in round robin=20=

> fashion. I don't know if this is in accordance with RFC 3484 or not,

i have read rfc3484 repeatedly lately and no mention  to this ....

>  maybe there is a longest match rule in there somewhere. But if so,=20
> that's a mistake as this example shows: it would make the host=20
> consistently choose a non-working address.
>
> (Note that even with round robin things may not work because the=20
> application won't try often enough to arrive at a working address=20
> pair. However, when the user makes the application retry eventually it=20=

> should work.)
>

agree

>> - For those apps that want to select the source address (i.e. they=20
>> use bind()) you let them take care of the problem, since it seems=20
>> they know what they are doing, since they are in fact already taking=20=

>> an explicit decision to set the source address. In this case, the app=20=

>> is the one performing the retrial,
>
> You are assuming that an application that does an explicit bind() for=20=

> outgoing sessions also retries.

well, not exactly.

i am saying that if the app does a bind() the stack below should=20
honnour this decision and there is not much left to do, but just=20
suggest to the app that it should retry with different source=20
addresses...

>  I don't think this is generally the case. For instance, the BIND=20
> named allows the user to set the source address which is useful=20
> because then other nameds know from which addresses they can expect=20
> sessions.
>
>> so the modification needed for rfc3484bis is just to guide the apps=20=

>> on how to retry. This basically means two thing: 1. rfc3484bis should=20=

>> state that apps need to retry using different source addresses when=20=

>> they are available. 2. the available source addresses associated to a=20=

>> destiantion address can be provided by rfc3484bis to the app in the=20=

>> form of an ordered list, so that the app has some guidance of which=20=

>> addresses to try first (similar to what is done with destination=20
>> address by current rfc3484)
>
> Yes, this is useful, but don't expect that application writers will=20
> all start doing this.
>

agree
the point is that apps should know that if they decide to go through=20
the path of selecting the source address, they need to deal with these=20=

issues.

>> - For those apps that do not select the source address, there are two=20=

>> options:
>>   - In the case of TCP, we can allow the rfc3484bis to tell the=20
>> socket to
>>     retry when a connect() is made. This means that the 3-way=20
>> handshake
>>     is retried with different source addresses until it is completed
>>   - In the UDP case, the situation is more difficult, because we =
don't
>>     have signaling packets to try with. In this case, i would suggest
>>     that rfc3484bis only keep some track of which source addresses
>>     seems not to be working with a given destiantion address, so that
>>     if the app retries, a different source address is tried( and we
>>     are not stuck with the same source address, as it is the current
>>     situation)
>
> Seems reasonable.
>
> But again, I don't think this is a full scale solution to the problem.
>
>

agree
this is just what i think it is the best we can do with the constraints=20=

imposed to the problem

probably, in order to provide a better support, we can came up with=20
improved mechanisms for the case where both peers support the shim

thanks for the feedback, marcelo

Delivery-date: Mon, 31 Oct 2005 12:37:36 +0000
Date: Mon, 31 Oct 2005 13:37:17 +0100
From: Pierre Baume <[email-masked]>
To: Tom Petch <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>

Dear all,

  RTO =3D Retransmission Timeout

http://www.google.com/search?q=3DRetransmission+Timeout+RTO

Pierre.

On 10/31/05, Tom Petch <[email-masked]> wrote:
> <inline>
> Tom Petch
>
> ----- Original Message -----
> From: "Iljitsch van Beijnum" <[email-masked]>
> To: "Jari Arkko" <[email-masked]>
> Cc: "shim6" <[email-masked]>; "Bernard Aboba" <[email-masked]>
> Sent: Monday, October 31, 2005 10:32 AM
> Subject: Re: Comments on draft-ietf-shim6-failure-detection
>
>
> > On 31-okt-2005, at 7:04, Jari Arkko wrote:
> >
> > > I am not clear that the "multi-homing protocol" necessarily has the
> > > right
> > > information to do testing and failure detection correctly.
> >
> > Since the multihoming / shim layer is the only one that is equipped
> > to take action to repair such failures I don't see how this could
> > work elsewhere. (There are some corner cases such as SCTP or
> > applications that can repair broken connectivity in some cases.)
> >
> > > For example, it does not make sense to diagnose a "connectivity
> > > problem"
> > > on a time scale less than RTO.  Yet only the tranport layer typically
> > > possesses the RTO estimate.
> >
> > RTO =3D=3D ? RT must be "roundtrip" but the O?
> >
>
> Aliter, TO must be Time Out but the R?  Response, Reply, Request?
>
> <snip>
>
>
>

Delivery-date: Mon, 31 Oct 2005 12:26:10 +0000
Cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Date: Mon, 31 Oct 2005 13:26:23 +0100
To: Paul Jakma <[email-masked]>

El 31/10/2005, a las 12:31, Paul Jakma escribi=F3:

>
>> First, you cannot assume that all hosts support the shim
>
> OK.
>

this, by itself would be enough to provide multihomed hosts some=20
mechanism to be able to establish new communications after an outage in=20=

one of their ISPs i.e. rfc3484 bis, agree?

>> Second, even if they do, such approach would imply that the shim=20
>> negotiation is made upfront i.e. that the shim session is established=20=

>> before the communication starts, which is completelly opposed to=20
>> current deferred context approach that is being followed throughout=20=

>> the shim6 design
>
> OK. I'm not sure why that's implied though. The shim could start off=20=

> with a NULL mapping (whatever the default source is, as decided by=20
> plain old SAS, probably routing policy). Given shim is to be able to=20=

> interject later on if required.. Also, if the application hasn't bound=20=

> to any specific address, then the shim can very easily put in whatever=20=

> address it wants to..
>
> I.e. If the default source doesn't work, shim6 kicks in and /then/=20
> *shim* can do source-address probing.
>
> Handy side-effect of only introducing these complications when there's=20=

> actually a problem, hence the 99% of connections which get setup when=20=

> things are working normally don't have to be encumbered with=20
> source-probing by all applications..
>

but in this would the app the one that triggers the shim? or would be=20
the shim that detects when there is a problem?...
i don't see how this works...

I am not sure if you are considering the case where the app selects the=20=

source address (uses bind()) or not... i asume that the source address=20=

is not set by the app.

So, the app tries to establish a communication. suppose that there is a=20=

failure in one of the isps.
the app tries to establish a communication without specifying a source=20=

address, and rfc3484 selects the address associated to the isp that is=20=

down.
Now, the packet with that src address never make it, so who detects=20
that there is a problem?
The shim? how is this done? i mean, the shim cannot know if there is an=20=

reply packet expected, since it is not aware of the app protocol.
The other option would the app, to notify the shim that something is=20
wrong and to try fix it... This would require a modification to the app=20=

and would only make sense of the other end supports the shim.
As i understand it, this is what we called "shim API on steroids" which=20=

would allow an app to tell the shim "i want to connect to hostX, you=20
find a working pair for me"
This is good, but it does not work with legacy hosts (that don't=20
support the shim), it imposes a shim negotiation upfront.
I like your point that this could be done only when the initial contact=20=

fails though (but i am not sure how to detect this failure)

So, as i see it:
- the API on steroids is a good feature that we want to have
- we need a rfc3484bis at least to support communications with non shim=20=

hosts and maybe it would be good to deal with the problem for=20
communications between shim hosts, depending on the result

>> So, we need to deal with the following situation:
>>
>>
>>
>>             /-- ( A ) ---(      )
>>   X (site X)             ( IPv6 ) ---(C)---(site Y)Y
>>             \-- ( B ) ---(      )
>>
>>
>> Where, host X supports multihoming features, something like an=20
>> rfc3484 bis and event the shim if you want, but host Y does NOT=20
>> support the shim. Suppose now that ISPA fails, what do you do?
>
>> If you base your solution in the shim, then if hostX can not=20
>> communicate with host Y using the shim.
>
>> If you don't let X use the shim, then how does it selects the source=20=

>> address?
>
> I must have missed a lot of developments in the direction shim in the=20=

> last month or two. I don't understand at all now. I had thought the=20
> intention was that shim could 'kick in', e.g. by opportunistically=20
> sending the first packet on without any shim6 setup (or minimal=20
> setup), was the impression I had from some other discussions.
>

please check draft-ietf-shim6-proto-02
there you will find that the shim6 protocol rqeuires a 4 way exchange=20
to establish the shim context, that needs to be done before the shim=20
translation between locators and ulids can be done

> You seem to be exploring a way to get some of the benefits of shim=20
> without ever having a shim involved at all, is that right?
>

right. 3 comments:
- this is only for initial contact (so no problem with breaking tcp=20
connection because using a different address, since the communication=20
is being established at this very moment)
- this assumes bidirectional working address pairs, (i.e. a single=20
address pair is used in both directions of the communication)
- it does not require special support from the peer (it works with=20
non-shim nodes)

>> If you use current rfc 3484 you are stuck in a single source address,=20=

>> so in case host X selects ISPA address as source address, he won't be=20=

>> able to communicate. How do you solve this problem?
>
> I'm confused now. I thought the whole point was for shim6 to solve=20
> that problem.
>

shim6 is focused in preserving established communications through=20
outages.
in shim6 protocol the main problem is that the address pair that is=20
currently being used for exchanging packets is no longer working, so we=20=

need to use a different address pair to route packets, but in order to=20=

preserve established connections (TCP for isntance) the address pair=20
presented to the upper layers must remain unchanged. that is why we=20
need this mapping performed by the shim and this is why we need support=20=

from both of the peers for this shim

In this other case, we are dealing with a different problem: how to=20
cope with failures during the initial contact?
In this case, the failure has occurred before the communication has=20
started. Then what we need is to find a working address pair. This=20
address pair is not fixed, because there is no established connection=20
(yet).
So, this problem can be solved without requiring support from both=20
peers i.e. a multihomed host implementing this can successfully=20
communicate with a regular ipv6 hosts that does not implement any=20
specific mechanism

So, this is a different problem with a different set of restrictions:
- address pair can change
- peer does not support any new mechanism

(as oposed to the shim6 protocol problem where:
- the address pair used by the upper layers is fixed
- the peer needs ti support the shim)

>> What i can think of is:
>
>> - For those apps that want to select the source address (i.e. they=20
>> use bind()) you let them take care of the problem, since it seems=20
>> they know what they are doing, since they are in fact already taking=20=

>> an explicit decision to set the source address. In this case, the app=20=

>> is the one performing the retrial, so the modification needed for=20
>> rfc3484bis is just to guide the apps on how to retry. This basically=20=

>> means two thing: 1. rfc3484bis should state that apps need to retry=20=

>> using different source addresses when they are available. 2. the=20
>> available source addresses associated to a destiantion address can be=20=

>> provided by rfc3484bis to the app in the form of an ordered list, so=20=

>> that the app has some guidance of which addresses to try first=20
>> (similar to what is done with destination address by current rfc3484)
>
> IOW, achieve the goals of shim but in the applications rather than in=20=

> a shim IP<->output layer in the IP implementation?
>

not exactly...
this only deals with problems during communication establishment phase,=20=

as opposed to the shim that deals with problems once established.

> I'd agree that's the most sensible way to implement this, in a perfect=20=

> world. But of course has pretty big deployment barrier, the entire=20
> reason for this WG in the first place.

right.
however, it seems that there are apps that select the source address=20
they want to use using bind(). For this it makes sense to provide some=20=

guidance of how this needs to be done
I am not saying that this is the only mechanism that we need to deal=20
with this, but what i am saying is that IF apps are going to select the=20=

source address, we need to provide guidance so that they do it properly=20=

taking into account that different source addresses need to be tried in=20=

case of a failure

> It could be done with some standardised APIs (which are not the remit=20=

> of the IETF to specify, but some nice API work has been documented in=20=

> informational RFCs).
>

well, rfc3484 state for instance that the app should iterate through=20
all the list of available destination addresses until one that is=20
working is found.
This is why it seems that rfc3484bis should be the place to state that=20=

in the case that multiple source addresses are available, the app that=20=

decides to set the source address using bind() should iterate through=20
all available source addresses until it finds one that is working

>
>> - For those apps that do not select the source address, there are two=20=

>> options:
>
>>  - In the case of TCP, we can allow the rfc3484bis to tell the socket=20=

>> to
>>    retry when a connect() is made. This means that the 3-way =
handshake
>>    is retried with different source addresses until it is completed
>
>>  - In the UDP case, the situation is more difficult, because we don't
>>    have signaling packets to try with. In this case, i would suggest
>>    that rfc3484bis only keep some track of which source addresses
>>    seems not to be working with a given destiantion address, so that
>>    if the app retries, a different source address is tried( and we
>>    are not stuck with the same source address, as it is the current
>>    situation)
>
>
>> This is what i can think as possible solutions to this problem. It=20
>> implies modifications to the apps in the case that is the app the one=20=

>> in charge of retrial,
>
> I would suggest doing it in the application (preferably in a nice=20
> widely available library) would be best.
>

I am not sure if i am following you...
for the tcp case, this can done in a fashion that it is transparent to=20=

the app
for the udp case, i am not sure how we can do this...

do you have any idea you could share?

>> but this seems to be in line with the fact that it is the app the one=20=

>> that is selecting the source address i.e. the app is involved to a=20
>> certain degree in this selection.
>
> Right, and it has the best view of its state.
>
>> Now do this still make no sense to you?
>
> It makes sense.
>
> I'm wondering about the motivation though, i.e. wrt the shim6=20
> IP-intermediary-layer approach, which I /thought/ was what ye were=20
> going with. ;) I'm confused on that point. The point that started this=20=

> sub-thread was Geoff's summary of the design decisions, where this SAS=20=

> by way of RFC3484 is to be the way for initial location:
>
> "1.  The specification for initial contact will use RFC3484, as=20
> modified by
>      this draft in terms of source address ordering."
>
> I still don't get why, if the intention is for this to be used /with/=20=

> shim6, this responsibility has to be punted to either the application=20=

> or to some algorithm which currently is stateless.
>
> Ie, why not let the modifications to SAS be specified as part of=20
> Shim6, in a context of "acting on behalf of the application" rather=20
> than "affecting the protocol".
>

i hope that with the above comment this is clearer
summarizing:
- we need something that does not involves the shim protocol to support=20=

communications with non shim hosts
- we could use this also for communications with shim enabled hosts=20
(depending how good is the outcome)
- we need also a API on steroids for the shim to benefit from the=20
special case where both peers supports the shim and improved=20
performance can be achieved

> Shim can simply act as the "agent" and implement the required SAS. It=20=

> needn't imply anything else of Shim, particularly the protocol side.=20=

> (ie, whether it must set things up in advance).
>

weel this is just another way to put it, right?
whether you call it shim without the shim protocol or rfc3484 bis, they=20=

would be local mechanisms for identifying non working source addresses=20=

and selecting those that are working, right?

regards, marcelo

Delivery-date: Mon, 31 Oct 2005 12:19:03 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6" <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection
Date: Mon, 31 Oct 2005 12:15:37 +0100

<inline>
Tom Petch

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Cc: "shim6" <[email-masked]>; "Bernard Aboba" <[email-masked]>
Sent: Monday, October 31, 2005 10:32 AM
Subject: Re: Comments on draft-ietf-shim6-failure-detection

> On 31-okt-2005, at 7:04, Jari Arkko wrote:
> 
> > I am not clear that the "multi-homing protocol" necessarily has the  
> > right
> > information to do testing and failure detection correctly.
> 
> Since the multihoming / shim layer is the only one that is equipped  
> to take action to repair such failures I don't see how this could  
> work elsewhere. (There are some corner cases such as SCTP or  
> applications that can repair broken connectivity in some cases.)
> 
> > For example, it does not make sense to diagnose a "connectivity  
> > problem"
> > on a time scale less than RTO.  Yet only the tranport layer typically
> > possesses the RTO estimate.
> 
> RTO == ? RT must be "roundtrip" but the O?
> 

Aliter, TO must be Time Out but the R?  Response, Reply, Request?

<snip>

Delivery-date: Mon, 31 Oct 2005 12:03:04 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Date: Mon, 31 Oct 2005 13:02:25 +0100
To: marcelo bagnulo braun <[email-masked]>

On 31-okt-2005, at 11:54, marcelo bagnulo braun wrote:

>> Is there any good reason why this retry/source-select state can  
>> not be kept inside the shim6 layer? The remit of shim6 is after  
>> all to handle this stuff transparently.

> Because:
> First, you cannot assume that all hosts support the shim

Well, if we can provide unmodified applications on shim-capable hosts  
with this functionality that would be very good. There are several  
advantages to using the shim here, including better opportunities for  
security and traffic engineering, although it would of course be nice  
if we could have the same functionality when one host doesn't support  
the shim.

> Second, even if they do, such approach would imply that the shim  
> negotiation is made upfront i.e. that the shim session is  
> established before the communication starts, which is completelly  
> opposed to current deferred context approach that is being followed  
> throughout the shim6 design

We don't have to change our current thinking for sessions where the  
initially chosen ULIDs are reachable: only when those turn out  
unreachable, we need to do additional work.

The main problems here are detecting that the initial ULID/locator  
pair doesn't work before we have any shim state we can use, and  
finding additional locators. HBA should allow us to make certain that  
these locators belong to the initially chosen ULID. However, it's  
possible that people publish AAAA records for different hosts that  
provide the same service so the HBA check would presumably not work  
then. So either we need something independent of AAAA records, or  
limit ourselves to the case where the AAAA addresses are part of the  
same HBA set.

Still, I'm not too worried about this, finding locators can be  
improved later.

BTW, being able to do the shim before communication starts also  
provides a good path towards something we'll want in the future:  
disjunct ULID/locator sets. Having a mechanism in place that allows  
using non-IPv6 ULIDs in the future would also help here.

> So, we need to deal with the following situation:

>              /-- ( A ) ---(      )
>    X (site X)             ( IPv6 ) ---(C)---(site Y)Y
>              \-- ( B ) ---(      )

> Where, host X supports multihoming features, something like an  
> rfc3484 bis and event the shim if you want, but host Y does NOT  
> support the shim.
> Suppose now that ISPA fails, what do you do?

Obviously not repair the failure using the shim...

So either use the "second shim" approach or hope that the application  
does the right thing.

> If you don't let X use the shim, then how does it selects the  
> source address?
> If you use current rfc 3484 you are stuck in a single source address,

In my experience hosts try different source addresses in round robin  
fashion. I don't know if this is in accordance with RFC 3484 or not,  
maybe there is a longest match rule in there somewhere. But if so,  
that's a mistake as this example shows: it would make the host  
consistently choose a non-working address.

(Note that even with round robin things may not work because the  
application won't try often enough to arrive at a working address  
pair. However, when the user makes the application retry eventually  
it should work.)

> - For those apps that want to select the source address (i.e. they  
> use bind()) you let them take care of the problem, since it seems  
> they know what they are doing, since they are in fact already  
> taking an explicit decision to set the source address. In this  
> case, the app is the one performing the retrial,

You are assuming that an application that does an explicit bind() for  
outgoing sessions also retries. I don't think this is generally the  
case. For instance, the BIND named allows the user to set the source  
address which is useful because then other nameds know from which  
addresses they can expect sessions.

> so the modification needed for rfc3484bis is just to guide the apps  
> on how to retry. This basically means two thing: 1. rfc3484bis  
> should state that apps need to retry using different source  
> addresses when they are available. 2. the available source  
> addresses associated to a destiantion address can be provided by  
> rfc3484bis to the app in the form of an ordered list, so that the  
> app has some guidance of which addresses to try first (similar to  
> what is done with destination address by current rfc3484)

Yes, this is useful, but don't expect that application writers will  
all start doing this.

> - For those apps that do not select the source address, there are  
> two options:
>   - In the case of TCP, we can allow the rfc3484bis to tell the  
> socket to
>     retry when a connect() is made. This means that the 3-way  
> handshake
>     is retried with different source addresses until it is completed
>   - In the UDP case, the situation is more difficult, because we don't
>     have signaling packets to try with. In this case, i would suggest
>     that rfc3484bis only keep some track of which source addresses
>     seems not to be working with a given destiantion address, so that
>     if the app retries, a different source address is tried( and we
>     are not stuck with the same source address, as it is the current
>     situation)

Seems reasonable.

But again, I don't think this is a full scale solution to the problem.

Delivery-date: Mon, 31 Oct 2005 11:32:18 +0000
Date: Mon, 31 Oct 2005 11:31:22 +0000 (GMT)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Mail-Copies-To: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--299119927-1869796508-1130757576=:6525
Content-Type: TEXT/PLAIN; CHARSET=utf-8; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <[email-masked]>

On Mon, 31 Oct 2005, marcelo bagnulo braun wrote:

> El 31/10/2005, a las 2:28, Paul Jakma escribió:

> thanks

Sorry ;).

> Because:

> First, you cannot assume that all hosts support the shim

OK.

> Second, even if they do, such approach would imply that the shim 
> negotiation is made upfront i.e. that the shim session is 
> established before the communication starts, which is completelly 
> opposed to current deferred context approach that is being followed 
> throughout the shim6 design

OK. I'm not sure why that's implied though. The shim could start off 
with a NULL mapping (whatever the default source is, as decided by 
plain old SAS, probably routing policy). Given shim is to be able to 
interject later on if required.. Also, if the application hasn't 
bound to any specific address, then the shim can very easily put in 
whatever address it wants to..

I.e. If the default source doesn't work, shim6 kicks in and /then/ 
*shim* can do source-address probing.

Handy side-effect of only introducing these complications when 
there's actually a problem, hence the 99% of connections which get 
setup when things are working normally don't have to be encumbered 
with source-probing by all applications..

> So, we need to deal with the following situation:
>
>
>
>             /-- ( A ) ---(      )
>   X (site X)             ( IPv6 ) ---(C)---(site Y)Y
>             \-- ( B ) ---(      )
>
>
> Where, host X supports multihoming features, something like an 
> rfc3484 bis and event the shim if you want, but host Y does NOT 
> support the shim. Suppose now that ISPA fails, what do you do?

> If you base your solution in the shim, then if hostX can not 
> communicate with host Y using the shim.

> If you don't let X use the shim, then how does it selects the 
> source address?

I must have missed a lot of developments in the direction shim in the 
last month or two. I don't understand at all now. I had thought the 
intention was that shim could 'kick in', e.g. by opportunistically 
sending the first packet on without any shim6 setup (or minimal 
setup), was the impression I had from some other discussions.

You seem to be exploring a way to get some of the benefits of shim 
without ever having a shim involved at all, is that right?

> If you use current rfc 3484 you are stuck in a single source 
> address, so in case host X selects ISPA address as source address, 
> he won't be able to communicate. How do you solve this problem?

I'm confused now. I thought the whole point was for shim6 to solve 
that problem.

> What i can think of is:

> - For those apps that want to select the source address (i.e. they 
> use bind()) you let them take care of the problem, since it seems 
> they know what they are doing, since they are in fact already 
> taking an explicit decision to set the source address. In this 
> case, the app is the one performing the retrial, so the 
> modification needed for rfc3484bis is just to guide the apps on how 
> to retry. This basically means two thing: 1. rfc3484bis should 
> state that apps need to retry using different source addresses when 
> they are available. 2. the available source addresses associated to 
> a destiantion address can be provided by rfc3484bis to the app in 
> the form of an ordered list, so that the app has some guidance of 
> which addresses to try first (similar to what is done with 
> destination address by current rfc3484)

IOW, achieve the goals of shim but in the applications rather than in 
a shim IP<->output layer in the IP implementation?

I'd agree that's the most sensible way to implement this, in a 
perfect world. But of course has pretty big deployment barrier, the 
entire reason for this WG in the first place. It could be done with 
some standardised APIs (which are not the remit of the IETF to 
specify, but some nice API work has been documented in informational 
RFCs).

Or have I completely missed the point? (again ;) ).

> - For those apps that do not select the source address, there are two 
> options:

>  - In the case of TCP, we can allow the rfc3484bis to tell the socket to
>    retry when a connect() is made. This means that the 3-way handshake
>    is retried with different source addresses until it is completed

>  - In the UDP case, the situation is more difficult, because we don't
>    have signaling packets to try with. In this case, i would suggest
>    that rfc3484bis only keep some track of which source addresses
>    seems not to be working with a given destiantion address, so that
>    if the app retries, a different source address is tried( and we
>    are not stuck with the same source address, as it is the current
>    situation)

> This is what i can think as possible solutions to this problem. It 
> implies modifications to the apps in the case that is the app the 
> one in charge of retrial,

I would suggest doing it in the application (preferably in a nice 
widely available library) would be best.

> but this seems to be in line with the fact that it is the app the 
> one that is selecting the source address i.e. the app is involved 
> to a certain degree in this selection.

Right, and it has the best view of its state.

> Now do this still make no sense to you?

It makes sense.

I'm wondering about the motivation though, i.e. wrt the shim6 
IP-intermediary-layer approach, which I /thought/ was what ye were 
going with. ;) I'm confused on that point. The point that started 
this sub-thread was Geoff's summary of the design decisions, where 
this SAS by way of RFC3484 is to be the way for initial location:

"1.  The specification for initial contact will use RFC3484, as modified by
      this draft in terms of source address ordering."

I still don't get why, if the intention is for this to be used /with/ 
shim6, this responsibility has to be punted to either the application 
or to some algorithm which currently is stateless.

Ie, why not let the modifications to SAS be specified as part of 
Shim6, in a context of "acting on behalf of the application" rather 
than "affecting the protocol".

Shim can simply act as the "agent" and implement the required SAS. It 
needn't imply anything else of Shim, particularly the protocol side. 
(ie, whether it must set things up in advance).

> If so, could you suggest approaches to deal with the problem and 
> the imposed constraints?

I'm afraid not, just suggesting that keeping the problem confined 
within shim6 (and any cousins, MIP, whatever) will be /less/ of a 
problem than the proposal of complicating SAS a lot for /all/ cases.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
It's been a business doing pleasure with you.
--299119927-1869796508-1130757576=:6525--

Delivery-date: Mon, 31 Oct 2005 10:54:55 +0000
Cc: Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
Date: Mon, 31 Oct 2005 11:54:45 +0100
To: [email-masked], shim6-wg <[email-masked]>

Hi Paul,

El 31/10/2005, a las 2:28, Paul Jakma escribi=F3:

> I don't think either approach makes sense :).
>

thanks

> Is there any good reason why this retry/source-select state can not be=20=

> kept inside the shim6 layer? The remit of shim6 is after all to handle=20=

> this stuff transparently.
>

Because:
First, you cannot assume that all hosts support the shim
Second, even if they do, such approach would imply that the shim=20
negotiation is made upfront i.e. that the shim session is established=20
before the communication starts, which is completelly opposed to=20
current deferred context approach that is being followed throughout the=20=

shim6 design

So, we need to deal with the following situation:

              /-- ( A ) ---(      )
    X (site X)             ( IPv6 ) ---(C)---(site Y)Y
              \-- ( B ) ---(      )

Where, host X supports multihoming features, something like an rfc3484=20=

bis and event the shim if you want, but host Y does NOT support the=20
shim.
Suppose now that ISPA fails, what do you do?
If you base your solution in the shim, then if hostX can not=20
communicate with host Y using the shim.
If you don't let X use the shim, then how does it selects the source=20
address?
If you use current rfc 3484 you are stuck in a single source address,=20
so in case host X selects ISPA address as source address, he won't be=20
able to communicate.
How do you solve this problem?

What i can think of is:
- For those apps that want to select the source address (i.e. they use=20=

bind()) you let them take care of the problem, since it seems they know=20=

what they are doing, since they are in fact already taking an explicit=20=

decision to set the source address. In this case, the app is the one=20
performing the retrial, so the modification needed for rfc3484bis is=20
just to guide the apps on how to retry. This basically means two thing:=20=

1. rfc3484bis should state that apps need to retry using different=20
source addresses when they are available. 2. the available source=20
addresses associated to a destiantion address can be provided by=20
rfc3484bis to the app in the form of an ordered list, so that the app=20
has some guidance of which addresses to try first (similar to what is=20
done with destination address by current rfc3484)

- For those apps that do not select the source address, there are two=20
options:
   - In the case of TCP, we can allow the rfc3484bis to tell the socket=20=

to
     retry when a connect() is made. This means that the 3-way handshake
     is retried with different source addresses until it is completed
   - In the UDP case, the situation is more difficult, because we don't
     have signaling packets to try with. In this case, i would suggest
     that rfc3484bis only keep some track of which source addresses
     seems not to be working with a given destiantion address, so that
     if the app retries, a different source address is tried( and we
     are not stuck with the same source address, as it is the current
     situation)

This is what i can think as possible solutions to this problem.
It implies modifications to the apps in the case that is the app the=20
one in charge of retrial, but this seems to be in line with the fact=20
that it is the app the one that is selecting the source address i.e.=20
the app is involved to a certain degree in this selection.

Now do this still make no sense to you?
If so, could you suggest approaches to deal with the problem and the=20
imposed constraints?

Regards, marcelo

> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> I have the simplest tastes.  I am always satisfied with the best.
> 		-- Oscar Wilde=

Delivery-date: Mon, 31 Oct 2005 09:44:39 +0000
From: Iljitsch van Beijnum <[email-masked]>
Subject: Presenting draft-ietf-shim6-reach-detect-01.txt, was: SHIM6 WG Agenda for IETF 64
Date: Mon, 31 Oct 2005 10:44:26 +0100
To: shim6 <[email-masked]>

On 17-okt-2005, at 7:45, Geoff Huston wrote:

> Site Multihoming by IPv6 Intermediation WG (SHIM6)

> AGENDA

> 6. Failure and Reacahability Detection - outstanding issues
>    Jari Akko & Iljitsch van Beijnum
>
>    Document:
>       draft-ietf-shim6-failure-detection-01
>       "Failure Detection and Locator Pair
>        Exploration Design for IPv6 Multihoming"
>                                     (50 minutes)

Since there hasn't been any discussion of the draft I wrote ( http:// 
www.ietf.org/internet-drafts/draft-ietf-shim6-reach-detect-01.txt )  
on the list so far, I think it's important that it's discussed in  
Vancouver. However, I won't be attending.

Is there someone who would be willing to present this draft?

(I would also be happy to talk about it remotely but I don't think  
there is precedent for that in IETF meetings.)

Delivery-date: Mon, 31 Oct 2005 09:34:48 +0000
Cc: shim6 <[email-masked]>, Bernard Aboba <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-failure-detection
Date: Mon, 31 Oct 2005 10:32:52 +0100
To: Jari Arkko <[email-masked]>

On 31-okt-2005, at 7:04, Jari Arkko wrote:

> I am not clear that the "multi-homing protocol" necessarily has the  
> right
> information to do testing and failure detection correctly.

Since the multihoming / shim layer is the only one that is equipped  
to take action to repair such failures I don't see how this could  
work elsewhere. (There are some corner cases such as SCTP or  
applications that can repair broken connectivity in some cases.)

> For example, it does not make sense to diagnose a "connectivity  
> problem"
> on a time scale less than RTO.  Yet only the tranport layer typically
> possesses the RTO estimate.

RTO == ? RT must be "roundtrip" but the O?

Trying to repair failures on a subsecond scale has many undesirable  
side effects. Until these are studied we should stay well away from  
this.

> Similarly, if the cause of the connectivity loss is a route flap, then
> only the routing layer might have knowledge of the loss of the  
> route, and
> only if it is participating in the routing mesh.

And if a failure occurs because the company went bankrupt only the  
CTO knows the details... But who cares? The point is that there is no  
longer any connectivity and it's impossible to make sure that the  
information about this finds its way to the hosts involved, so these  
hosts must discover this by themselves.

> For example, in adhoc
> networks, missing routes are a frequent contributor to packet loss, so
> that integration of the routing and transport layers is required to be
> able to respond  appropriately.

What would a host do differently if it has this knowledge?

> The application layer does have the ability to diagnose connectivity
> problems on the order of seconds, through keep-alives.

Keepalives are bad; they waste bandwidth. Applications shouldn't use  
them.

Delivery-date: Mon, 31 Oct 2005 06:04:45 +0000
Date: Mon, 31 Oct 2005 08:04:09 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
CC: Bernard Aboba <[email-masked]>
Subject: FW: Comments on draft-ietf-shim6-failure-detection

Here are some comments from Bernard Aboba. These relate to
the failure and reachability detection and perhaps also more
generally the division of work between the shim and
other protocol layers. I wasn't quite sure what to say
in response, so with Bernard's permission, I'm posting
the comments here:

----

I read the SHIM6 failure detection documents, and had some comments
relating to the time scale of failure detection.  I think there are some
issues with respect to "conservation of packets" that are worth exploring.

Section 5

    Also, it
    would be unfortunate if both the IP layer and transport/application
    layer took action for the same problem, for instance by switching to
    a new address at the IP layer and throttling back due to "congestion"
    at the transport layer.

This is not necessarily undesirable.  If the path over which a TCP
connection
travels changes, the transport parameters may have become invalid.  In
such
a situation, studies have shown that re-estimation actually may improve
performance, as compared to continuing to operate with potentially invalid
values.

I would therefore argue that the important issue is not action
in multiple layers, but rather the avoidance of race conditions;  a
well-defined communication mechanism between the IP and
transport/application
layer can help with this.

    But it is less clear which protocol(s) should discover end-to-end
    connectivity problems or recover from them.  One answer is that this
    is clearly within the domain of multihoming protocol.  By performing
    testing and failure detection of the used path and switching to a new
    path if necessary, the transport and application protocols can work
    unchanged.

I am not clear that the "multi-homing protocol" necessarily has the right
information to do testing and failure detection correctly.

For example, it does not make sense to diagnose a "connectivity problem"
on a time scale less than RTO.  Yet only the tranport layer typically
possesses the RTO estimate.

Similarly, if the cause of the connectivity loss is a route flap, then
only the routing layer might have knowledge of the loss of the route, and
only if it is participating in the routing mesh.  For example, in adhoc
networks, missing routes are a frequent contributor to packet loss, so
that integration of the routing and transport layers is required to be
able to respond  appropriately.

On a global scale, BGP route flaps can last for a few seconds (though
rarely longer than 30 seconds), suggesting a minimum time scale on which
"connectivity loss" can be detected (this is why RFC 3539 timers are set
at a minimum of 6 seconds, but at a default value of 30 seconds).

    One can also envision that applications would be able to tell the IP
    or transport layer that the current connection is unsatisfactory and
    an exploration for a better one would be desirable.  This would
    require an API to be developed, however.

The application layer does have the ability to diagnose connectivity
problems on the order of seconds, through keep-alives.   The IP layer
generally does not have the ability to detect whether a connection is
"satisfactory" since it does not have access to the TCB, only
knowledge of potential causes of connectivity problems (such as path
changes or missing routes), which it can provide to the transport layer
or to applications.

Delivery-date: Mon, 31 Oct 2005 02:36:25 +0000
Date: Mon, 31 Oct 2005 03:35:43 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?

marcelo bagnulo braun wrote:
> Hi Brian,
> 
> I think this topic is interesting indeed and i share Geoff feeling about 
> complexity, but let me ask a bit more about this:
> 
> El 20/10/2005, a las 15:08, Brian E Carpenter escribió:
> 
>> There's quite a lot in the draft about how preferences are communicated
>> and very little about where they come from. draft-ietf-shim6-arch-00.txt
>> doesn't help with this either. Somewhere, I think we need a list
>> of possible sources of these preferences, and dynamic or static TE policy
>> needs to be in that list.
>>
> 
> what sources do you have in mind here?
> - i can clearly see that local preferences like the local admin setting 
> the local policy table to prefer some addresses over the others would 
> make sense. This would basically affect the selection of source 
> addresses and destiantions addresses used as ulids, as in the policy 
> table of rfc3484 and hence the locator used until a failure occurs. In 
> addition, a similar mechanism could be available for following locators 
> (after an outage)
> 
> - however, there seems to be other players that may want to also 
> influence in the preferences i.e. to be a source of preferences, in 
> particular, the peer. The peer can convey preferences about which 
> locators it want to use (this would only affect locators after a 
> rehoming event, since these preferences are conveyed once the session is 
> established so they are not good for selecting the initial 
> ulids/locators) (i can see some value on this, depending on the 
> scenario, as it has been discussed here)
> 
> Now, are you also considering here the isps as possible sources for 
> preference settings on a shim6 host? i mean, do you think that transit 
> provider should have the possibility to inform the shim hosts about what 
> locators it prefers?

Yes, though I would see it as more likely that the ISP would inform
the site border routers and they would distribute the preferences
to all hosts in the site, merged with any general site preferences
due to local policy.

     Brian

> 
> regards, marcelo
> 
> 
>> Some discussion of traffic engineering in the architecture document
>> would also seem necessary.
>>
>>     Brian
>>
>>
> 
> 

Delivery-date: Mon, 31 Oct 2005 01:30:09 +0000
Date: Mon, 31 Oct 2005 01:28:27 +0000 (GMT)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], shim6-wg <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Mail-Copies-To: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--299119927-2072628391-1130720271=:6525
Content-Type: TEXT/PLAIN; CHARSET=utf-8; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <[email-masked]>

On Thu, 27 Oct 2005, marcelo bagnulo braun wrote:
> El 27/10/2005, a las 17:08, Iljitsch van Beijnum escribió:

>> significant number of IPv6 applications doesn't either. I don't 
>> see applications cycle through all source/dest pairs because 
>> that's very hard to do right.

Indeed.

> not really understand what is the part that you think it is hard....

It's not particularly easy to do in a portable manner at present, the 
only semi-portable interface is the BSD IFCONF ioctl(), but it gives 
you a lot of detail and you then have to understand the differences 
in those details between those systems. Very easy to get it wrong. 
It's even more fun if you want to stay abreast of changes to 
configured addresses.

If you go down this road make sure to specify that an implementation 
SHOULD provide a means for an application to retrieve a simple list 
of candidate addresses (possibly sorted by preference determined by 
whatever local policy).

>> So either we have three choices:
>> 
>> 1. adopt the "second shim" to do this for the application
>> 2. make it possible to repair the situation where there is no reachability 
>> between the ULIDs from the start.
>> 3. update RFC 3484 and wait for all applications to be updated
>> 
>> I believe 3. won't work in practice and if it did, it would be a huge 
>> duplication of effort as all applications would have to implement the same 
>> functionality. Remember that we chose to make the shim such that unmodified 
>> applications can benefit from it.

Concur strongly.

> I think we could have 3 approaches (which can be complementary i.e. does not 
> have to be one or the other)

> - first approach is to let the app take care of everything
>  i.e. inform the app about all src and dst address and let
>  the app try all the possible combinations.

This seems contraversial - it's completely wrong for general case 
IPv6 (no shim involved). Applications have no business interfering 
with things normally determined by local routing policy, least not by 
default.

At least, it'd be a fundamental change in existing practice.

> - a second approach would be similar to the current case where the
>  app does not select the src address. In this case, the rfc3484bis
>  src address selection mechanism would need to use a different
>  src address each time the apps retries.

This really won't fly - it introduces state into source address 
selection which just is not there, i.e. whether application is 
retrying or not. (Never mind the previous point, which still applies 
in this case).

Introducing such state would require quite fundamental changes to 
existing application interfaces.

> I think that the first two approaches make sense and that it would 
> be useful to incoporate information about incoming address pairs as 
> a hint to select outgoing address pairs that are working.

I don't think either approach makes sense :).

Is there any good reason why this retry/source-select state can not 
be kept inside the shim6 layer? The remit of shim6 is after all to 
handle this stuff transparently.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
I have the simplest tastes.  I am always satisfied with the best.
 		-- Oscar Wilde
--299119927-2072628391-1130720271=:6525--

Delivery-date: Fri, 28 Oct 2005 16:35:19 +0000
Date: Fri, 28 Oct 2005 19:34:07 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

On Fri, 28 Oct 2005, Iljitsch van Beijnum wrote:
>> 1) Specifying such a rule is safe if it's known that the firewall would 
>> only accept packets with a particular header type if there is no proceeding 
>> header.
>
> No header following the one that the firewall is looking at, you mean?
>
> Well, if the firewall doesn't understand the shim header, how would it know 
> whether other headers follow the shim header? (Next header field isn't 
> necessarily in the same place in all headers. The prime example is ESP where 
> it actually follows the "next" header data.)
>
> And if the firewall does understand the shim header, it can obviously 
> interpret the TCP/UDP/other header that follows so there is no reason for the 
> firewall to behave in the way you mentioned.

All the non-final extension headers except fragment header have the 
same TLV format.  At least one firewall implementor has stated to use 
this logic, but I don't know if/how they differentiate "extension 
headers" and arbitrary data packets.

Even though this case was considered marginal enough we should 
evaluate whether requiring the use of an extension header is expected 
to be useful enough.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 16:03:41 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]
Date: Fri, 28 Oct 2005 18:03:16 +0200
To: Pekka Savola <[email-masked]>

On 28-okt-2005, at 14:20, Pekka Savola wrote:

>>> The last sentence does not follow.  Firewalls may accept just  
>>> fine packets with a shim6 extension header but no data, but could  
>>> (and I'd expect many WOULD) drop packets with shim6 ext header  
>>> WITH data.

>> Why??

> A site administrator may be able to specify in the firewall rules  
> that a particular next-header type should be accepted.

So far so good.

> 1) Specifying such a rule is safe if it's known that the firewall  
> would only accept packets with a particular header type if there is  
> no proceeding header.

No header following the one that the firewall is looking at, you mean?

Well, if the firewall doesn't understand the shim header, how would  
it know whether other headers follow the shim header? (Next header  
field isn't necessarily in the same place in all headers. The prime  
example is ESP where it actually follows the "next" header data.)

And if the firewall does understand the shim header, it can obviously  
interpret the TCP/UDP/other header that follows so there is no reason  
for the firewall to behave in the way you mentioned.

> 2) Specifying such a rule would result in completely open firewall  
> policy if the firewall cannot parse the next headers but would  
> accept packets if there was one.

We can debate "completely" but your point is clear.

> I don't think there are many acl implementations which are smart  
> enough to parse TCP/UDP ports, etc. after the extension headers.

I did a quick test with Cisco IPv6 access lists some time ago and  
they didn't "catch" TCP following AH, so it's certainly true that at  
least some filters don't look past the first header following the  
IPv6 header.

Fortunately, that's not our problem.

Delivery-date: Fri, 28 Oct 2005 15:55:02 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]
Date: Fri, 28 Oct 2005 17:54:22 +0200
To: Jari Arkko <[email-masked]>

On 28-okt-2005, at 14:20, Jari Arkko wrote:

>>> The last sentence does not follow.  Firewalls may accept just  
>>> fine  packets with a shim6 extension header but no data, but  
>>> could (and  I'd expect many WOULD) drop packets with shim6 ext  
>>> header WITH data.

>> Why??

> The same said firewalls could be dropping packets that are part
> of a TCP stream that was not initiated through this firewall...

Yes, but this is a known complication when setting up firewalls next  
to egress points as with BGP multihoming it's exceedingly common for  
packets to go out on one external link and the return packets to come  
in through another.

This is unrelated to the presence or absence of headers.

Delivery-date: Fri, 28 Oct 2005 12:25:14 +0000
Date: Fri, 28 Oct 2005 15:24:07 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

On Fri, 28 Oct 2005, Jari Arkko wrote:
>> But if that's true: all the more reason to support suppressing the  shim 
>> header for rewritten packets.  :-)
>
> The same said firewalls could be dropping packets that are part
> of a TCP stream that was not initiated through this firewall...

1) tcp stream could have been initiated through the firewall -- all 
depends on the firewalls placement

2) if there are multiple, they often have methods to sync their rules 
and state.

3) the fw could have policies which are lax enough "allow tcp 
established" which is often the case if 2) cannot apply.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 12:21:37 +0000
Date: Fri, 28 Oct 2005 15:20:32 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

On Fri, 28 Oct 2005, Iljitsch van Beijnum wrote:
> On 28-okt-2005, at 13:58, Pekka Savola wrote:
>>> [...] Since the fact that the shim signalling worked indicates that the 
>>> shim header isn't filtered this should work without trouble.
>
>> The last sentence does not follow.  Firewalls may accept just fine packets 
>> with a shim6 extension header but no data, but could (and I'd expect many 
>> WOULD) drop packets with shim6 ext header WITH data.
>
> Why??

A site administrator may be able to specify in the firewall rules that 
a particular next-header type should be accepted.

1) Specifying such a rule is safe if it's known that the firewall 
would only accept packets with a particular header type if there is no 
proceeding header.

2) Specifying such a rule would result in completely open firewall 
policy if the firewall cannot parse the next headers but would accept 
packets if there was one.

I don't think there are many acl implementations which are smart 
enough to parse TCP/UDP ports, etc. after the extension headers.

> But if that's true: all the more reason to support suppressing the shim 
> header for rewritten packets.  :-)

Exactly..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 12:20:50 +0000
Date: Fri, 28 Oct 2005 15:20:40 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Pekka Savola <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

>> The last sentence does not follow.  Firewalls may accept just fine  
>> packets with a shim6 extension header but no data, but could (and  
>> I'd expect many WOULD) drop packets with shim6 ext header WITH data.
>
>
> Why??
>
> But if that's true: all the more reason to support suppressing the  
> shim header for rewritten packets.  :-)

The same said firewalls could be dropping packets that are part
of a TCP stream that was not initiated through this firewall...

Either that or Pekka's dropping example would cause significant
problem for Shim6. I'm not sure Iljitsch's optimization is the answer,
because it does not work in all cases.

--Jari

Delivery-date: Fri, 28 Oct 2005 12:05:24 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]
Date: Fri, 28 Oct 2005 14:04:54 +0200
To: Pekka Savola <[email-masked]>

On 28-okt-2005, at 13:58, Pekka Savola wrote:

>> [...] Since the fact that the shim signalling worked indicates  
>> that the shim header isn't filtered this should work without trouble.

> The last sentence does not follow.  Firewalls may accept just fine  
> packets with a shim6 extension header but no data, but could (and  
> I'd expect many WOULD) drop packets with shim6 ext header WITH data.

Why??

But if that's true: all the more reason to support suppressing the  
shim header for rewritten packets.  :-)

Delivery-date: Fri, 28 Oct 2005 12:00:07 +0000
Date: Fri, 28 Oct 2005 14:58:53 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

On Fri, 28 Oct 2005, Iljitsch van Beijnum wrote:
>> - if it's done by adding an extension header to data packets, or
>
>> - if it would be done by sending separate "shim control packets" (e.g., 
>> with TCP, UDP, or whatever, or even plain extension headers without any 
>> data), then my concern still applies.
....
> No, I think we pretty much agree that the shim signalling would have to 
> happen in separate packets. Unless I misremember we didn't even discuss this 
> issue in the interim meeting.
...
> [...] Since the fact that the 
> shim signalling worked indicates that the shim header isn't filtered this 
> should work without trouble.

The last sentence does not follow.  Firewalls may accept just fine 
packets with a shim6 extension header but no data, but could (and I'd 
expect many WOULD) drop packets with shim6 ext header WITH data.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 11:50:27 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]
Date: Fri, 28 Oct 2005 13:49:37 +0200
To: Pekka Savola <[email-masked]>

On 28-okt-2005, at 12:42, Pekka Savola wrote:

>>> Otherwise the firewalls, packet filters etc. will just discard  
>>> all of these packets with the extension header because they don't  
>>> have the logic to skip over them or parse them.

Well obviously we expect the makers of these products to update their  
stuff.

In the mean time, our main concern here should be that the presence  
of any type of filtering leads to consistent results. If all shim  
packets are filtered that isn't so bad, because it then just seems  
that the correspondent doesn't support the shim so the session  
remains in backward compatible mode. The situation where the shim  
seems to be working but doesn't is much more destructive.

>> So if firewalls were to discard data packets carrying the shim ext  
>> header, they would have discarded the shim context establishment  
>> packets, so no shim context at all, so those data packets with the  
>> shim ext header will never be generated anyway, right?

> I assume that the method of establishing the shim context is still  
> open:

>  - if it's done by adding an extension header to data packets, or

>  - if it would be done by sending separate "shim control  
> packets" (e.g., with TCP, UDP, or whatever, or even plain extension  
> headers without any data), then my concern still applies.

No, I think we pretty much agree that the shim signalling would have  
to happen in separate packets. Unless I misremember we didn't even  
discuss this issue in the interim meeting.

The part that we're not completely agreeing on is whether all  
rewritten packets should have a shim header for demultiplexing. (This  
shim header would have the same protocol number as the shim  
signalling packets but otherwise be formatted completely differently.)

Erik has proposed a mechanism to allow demultiplexing based on the  
protocol and flow label fields. However, in the meeting it was  
proposed to simply use an explicit header instead. I think that makes  
lots of sense in the cases where demultiplexing would otherwise be  
impossible or difficult, but the discussion that I started was about  
having this header when demultiplexing without the header is NOT  
problematic.

> I do NOT want that shim6 would require piggybacking on data packets  
> either to establish the context or rehome.

I don't think in the case of data packets with rewritten addresses  
that are otherwise indistinguishable from data packets with the  
original addresses (i.e., when there is a session between A1 and B1  
and a session between A2 and B2 and then a failure between A1 and B1  
packets between A2 and B2 may either be the first session with  
rewritten addresses or the second with the original addresses) and/or  
when there are additional intermediate headers so it's not obvious  
which onces come "before" the shim and which ones come "after" it  
should be considered "piggybacking". In IPv6 a protocol chain is part  
of the base mechanism so there is no reason not to use extra headers  
when they are appropriate. (Obviously things would have been much  
better if there had been a standard header format so implementations  
would be able to skip unknown headers, but I guess we'll have to fix  
that in IPv7.) Since the fact that the shim signalling worked  
indicates that the shim header isn't filtered this should work  
without trouble.

Delivery-date: Fri, 28 Oct 2005 10:42:31 +0000
Date: Fri, 28 Oct 2005 13:42:06 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked], Geoff Huston <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

On Fri, 28 Oct 2005, marcelo bagnulo braun wrote:
> ok, let's first be very concise of what is being considered here:
> - in general data packets won't carry any shim extension header, because in 
> general, they will use the ulids as locators, so no need to demux.
> - the case where they carry the extension header if after an outage when the 
> locators carried differ from the ulids used in this shim context

Yes, this is clear.

>> Otherwise the firewalls, packet filters etc. will just discard all of these 
>> packets with the extension header because they don't have the logic to skip 
>> over them or parse them.
>
> but remember that the extension header included in data packets that need it, 
> it is the same used for shim control signaling, in particular, for 
> establishing the shim context. So if firewalls were to discard data packets 
> carrying the shim ext header, they would have discarded the shim context 
> establishment packets, so no shim context at all, so those data packets with 
> the shim ext header will never be generated anyway, right?

I assume that the method of establishing the shim context is still 
open:

  - if it's done by adding an extension header to data packets, or

  - if it would be done by sending separate "shim control packets" 
(e.g., with TCP, UDP, or whatever, or even plain extension headers 
without any data), then my concern still applies.

I do NOT want that shim6 would require piggybacking on data packets 
either to establish the context or rehome.  Logically separate 
functionality is what the base spec should target -- piggybacking as 
an optimization can be described however.

Piggybacking is not a trivial operation for many reasons, and it's 
problems have been considered in the past as well (e.g., with MIPv6 
design).  Tying it too strongly to the shim6 spec would seem unwise as 
we don't know how well it'd _really_ work.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 10:24:18 +0000
Date: Fri, 28 Oct 2005 13:24:14 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>,  Pekka Savola <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
CC:  [email-masked]
Subject: Shim-header in every re-located packet (Was: Re: Design decisions made at the interim SHIM6 WG meeting)

My take on this issue is that the benefits of optimizing some
bytes away in a failure case do not outweigh the costs. Shim6
header usage in every instance where non-initial locators are
used is very simple to implement, specify, analyze, and look
at by debuggers/firewalls etc.

Also, I don't see any drawbacks in making such optimizations
extensions that we define later. It seems that the initial shim6
exchange can in any case carry payloads/options that can be
used to negotiate features on or off.

--Jari

marcelo bagnulo braun wrote:

> Hi Pekka,
>
> El 28/10/2005, a las 11:52, Pekka Savola escribió:
>
>> On Thu, 27 Oct 2005, Iljitsch van Beijnum wrote:
>>
>>>> 2.  Use an 8 byte IP SHIM6 header in the base protocol 
>>>> specification for
>>>>    packets that require specific SHIM6 processing by the receiver, and
>>>>    allow optimizations on this, including that of a zero-length 
>>>> header, to
>>>>    be an experimental protocol extension.
>>>
>>>
>>> I have no problem with a shim header for demultiplexing in cases 
>>> where demultiplexing would otherwise be very hard or impossible. For 
>>> instance, in the case of several extension headers, an explicit shim 
>>> header makes it possible to indicate which headers see modified 
>>> addresses and which headers see unmodified addresses unambiguously.
>>>
>>> However, I think it's a very bad idea to have a shim header in EVERY 
>>> packet with rewritten addresses, because there are cases where the 
>>> shim context can be determined from information that's already in 
>>> the packet unambiguously so an extra header is unnecessary.
>>>
>>> Mandating a shim header first and then optionally allow it to be 
>>> suppressed is useless in practice: we need have the capability to 
>>> have the shim header suppressed as a mandatory part of the inital 
>>> base spec.
>>
>>
>> I have to echo Iljitsch here.  The possibility to do away with an 
>> extension header in the data packets (I don't care what the shim 
>> signalling looks like if it isn't piggybacked in the data packets) is 
>> one of the most important features of shim6 in my opinion.
>>
>
> ok, let's first be very concise of what is being considered here:
> - in general data packets won't carry any shim extension header, 
> because in general, they will use the ulids as locators, so no need to 
> demux.
> - the case where they carry the extension header if after an outage 
> when the locators carried differ from the ulids used in this shim context
>
> so there is not that all data packets of shim enabled communications 
> will carry the extension header, but only those communications that 
> have suffered and outage.
>
>> Putting that as an experimental feature,
>
>
> the porposal is not to put is as an experimental feature, like an 
> exprimental track spec, but as an extension to the basic spec, i.e. 
> not to included in the base spec
>
>>  to be defined later etc. is not acceptable IMHO.  This needs to be 
>> used and supported from day one.
>>
>
> the problem here is that the actual solution does looks somehow 
> complex and hacky at this point in time, and in order to understand 
> how complex and hacky it would be we rather see it fleshed out in a draft
>
> In particular, it seems to require overloading both the flow label and 
> the next header fields to carry other information that they were 
> designed to.
>
>> Otherwise the firewalls, packet filters etc. will just discard all of 
>> these packets with the extension header because they don't have the 
>> logic to skip over them or parse them.
>
>
> but remember that the extension header included in data packets that 
> need it, it is the same used for shim control signaling, in 
> particular, for establishing the shim context. So if firewalls were to 
> discard data packets carrying the shim ext header, they would have 
> discarded the shim context establishment packets, so no shim context 
> at all, so those data packets with the shim ext header will never be 
> generated anyway, right?
>
> regards, marcelo
>
>
>>   If we need to define it separately, I'd suggest we publish the 
>> whole shim6 spec as experimental first.
>>
>> -- 
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>>
>
>
>
>

Delivery-date: Fri, 28 Oct 2005 10:15:34 +0000
Cc: [email-masked], Geoff Huston <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Fri, 28 Oct 2005 12:15:38 +0200
To: Pekka Savola <[email-masked]>

Hi Pekka,

El 28/10/2005, a las 11:52, Pekka Savola escribi=F3:

> On Thu, 27 Oct 2005, Iljitsch van Beijnum wrote:
>>> 2.  Use an 8 byte IP SHIM6 header in the base protocol specification=20=

>>> for
>>>    packets that require specific SHIM6 processing by the receiver,=20=

>>> and
>>>    allow optimizations on this, including that of a zero-length=20
>>> header, to
>>>    be an experimental protocol extension.
>>
>> I have no problem with a shim header for demultiplexing in cases=20
>> where demultiplexing would otherwise be very hard or impossible. For=20=

>> instance, in the case of several extension headers, an explicit shim=20=

>> header makes it possible to indicate which headers see modified=20
>> addresses and which headers see unmodified addresses unambiguously.
>>
>> However, I think it's a very bad idea to have a shim header in EVERY=20=

>> packet with rewritten addresses, because there are cases where the=20
>> shim context can be determined from information that's already in the=20=

>> packet unambiguously so an extra header is unnecessary.
>>
>> Mandating a shim header first and then optionally allow it to be=20
>> suppressed is useless in practice: we need have the capability to=20
>> have the shim header suppressed as a mandatory part of the inital=20
>> base spec.
>
> I have to echo Iljitsch here.  The possibility to do away with an=20
> extension header in the data packets (I don't care what the shim=20
> signalling looks like if it isn't piggybacked in the data packets) is=20=

> one of the most important features of shim6 in my opinion.
>

ok, let's first be very concise of what is being considered here:
- in general data packets won't carry any shim extension header,=20
because in general, they will use the ulids as locators, so no need to=20=

demux.
- the case where they carry the extension header if after an outage=20
when the locators carried differ from the ulids used in this shim=20
context

so there is not that all data packets of shim enabled communications=20
will carry the extension header, but only those communications that=20
have suffered and outage.

> Putting that as an experimental feature,

the porposal is not to put is as an experimental feature, like an=20
exprimental track spec, but as an extension to the basic spec, i.e. not=20=

to included in the base spec

>  to be defined later etc. is not acceptable IMHO.  This needs to be=20
> used and supported from day one.
>

the problem here is that the actual solution does looks somehow complex=20=

and hacky at this point in time, and in order to understand how complex=20=

and hacky it would be we rather see it fleshed out in a draft

In particular, it seems to require overloading both the flow label and=20=

the next header fields to carry other information that they were=20
designed to.

> Otherwise the firewalls, packet filters etc. will just discard all of=20=

> these packets with the extension header because they don't have the=20
> logic to skip over them or parse them.

but remember that the extension header included in data packets that=20
need it, it is the same used for shim control signaling, in particular,=20=

for establishing the shim context. So if firewalls were to discard data=20=

packets carrying the shim ext header, they would have discarded the=20
shim context establishment packets, so no shim context at all, so those=20=

data packets with the shim ext header will never be generated anyway,=20
right?

regards, marcelo

>   If we need to define it separately, I'd suggest we publish the whole=20=

> shim6 spec as experimental first.
>
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

Delivery-date: Fri, 28 Oct 2005 09:54:12 +0000
Date: Fri, 28 Oct 2005 12:52:43 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

On Thu, 27 Oct 2005, Iljitsch van Beijnum wrote:
>> 2.  Use an 8 byte IP SHIM6 header in the base protocol specification for
>>    packets that require specific SHIM6 processing by the receiver, and
>>    allow optimizations on this, including that of a zero-length header, to
>>    be an experimental protocol extension.
>
> I have no problem with a shim header for demultiplexing in cases where 
> demultiplexing would otherwise be very hard or impossible. For instance, in 
> the case of several extension headers, an explicit shim header makes it 
> possible to indicate which headers see modified addresses and which headers 
> see unmodified addresses unambiguously.
>
> However, I think it's a very bad idea to have a shim header in EVERY packet 
> with rewritten addresses, because there are cases where the shim context can 
> be determined from information that's already in the packet unambiguously so 
> an extra header is unnecessary.
>
> Mandating a shim header first and then optionally allow it to be suppressed 
> is useless in practice: we need have the capability to have the shim header 
> suppressed as a mandatory part of the inital base spec.

I have to echo Iljitsch here.  The possibility to do away with an 
extension header in the data packets (I don't care what the shim 
signalling looks like if it isn't piggybacked in the data packets) is 
one of the most important features of shim6 in my opinion.

Putting that as an experimental feature, to be defined later etc. is 
not acceptable IMHO.  This needs to be used and supported from day 
one.

Otherwise the firewalls, packet filters etc. will just discard all of 
these packets with the extension header because they don't have the 
logic to skip over them or parse them.  If we need to define it 
separately, I'd suggest we publish the whole shim6 spec as 
experimental first.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Fri, 28 Oct 2005 09:28:55 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Fri, 28 Oct 2005 11:29:01 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/10/2005, a las 21:37, Iljitsch van Beijnum escribi=F3:
>>> What RFC does is two things:
>
>>> 1. select source and destination addresses
>>> 2. tell application programmers to cycle through all destination=20
>>> addresses
>
>> kind of agree...
>> i would say that rfc3484 does:
>> - it passes an ordered list of destiantion addresses to the app and=20=

>> requires that the app should cycle through all of them until finds=20
>> one that is reachable
>> - it selects a source address for a given destiantion address when=20
>> the app does not select one
>
> Actually, looking over the RFC very quickly, it doesn't look like RFC=20=

> 3484 requires applications to cycle through all available=20
> (destination) addresses.
>

Section 2 states that:

    Well-behaved applications SHOULD iterate through the list of
    addresses returned from getaddrinfo() until they find a working
    address.

>>> Most IPv4 applications don't cycle through all destination=20
>>> addresses, and a significant number of IPv6 applications doesn't=20
>>> either. I don't see applications cycle through all source/dest pairs=20=

>>> because that's very hard to do right.
>
>> not really understand what is the part that you think it is hard....
>
> Specifying an address with bind() is of course not problematic. The=20
> trouble is maintaining an up to date list of available addresses in=20
> the system. Since this list is subject to change applications would=20
> have to query all available addresses prior to any TCP session=20
> establishments and the like. Also, when the application has this list=20=

> of addresses, it somehow needs to go back to the system to have RFC=20
> 3484 policies applied to the source/dest pairs.
>

right this is what rfc3484bis needs to specify how is done

>> I think we could have 3 approaches (which can be complementary i.e.=20=

>> does not have to be one or the other)
>> - first approach is to let the app take care of everything
>>   i.e. inform the app about all src and dst address and let
>>   the app try all the possible combinations.
>>   This is the minimum change to rfc3484 bis, i.e. state that
>>   apps SHOULD retry with all possible src,dst pairs
>>   A possible optimization for this, would be that the rfc3484
>>   delivers an ordered list of address pairs (similar than current
>>   rfc3484 delivers a ordered list of dst address, the rfc3484bis
>>   would deliver to the app an ordered list of address pairs (based
>>   on rules for prefering one address pair over the other)
>>   [an alternative to this that would be more compatible with current
>>   rfc3484 would that for a given dst address, rfc3484bis would
>>   provide an ordered list or src addresses for this dst address]
>
> I suppose this is possible although I don't find it very desireable.
>
> If applications have to be changed anyway, why not come up with an API=20=

> that REALLY solves all of this?
>

but i think that we need to support the case where the app want to=20
select addresses (src and dst) that i wants to use. In this case, it=20
would make sense to allow rfc3484bis to provide some guidance about:
- that the app should retry using not only different dst addresses but=20=

also different src addresses
- some guidance about which pair of src, dst address would be better to=20=

try first i.e. an ordered list of address pairs or at least for each=20
dst address listed in the ordered list of dst address, provide an=20
ordered list of src addresses to try.

This of course is not opposed to other approaches as the ones mentioned=20=

below. I think that we are just dealing with different scenarios, with=20=

progressive app involvement:
- in this case, the app wants to select the address pair to use, so=20
let's allow rfc3484 bis to provide some guidance
- in the next case, the app will retry (i.e. determine when the packet=20=

didn't make it) but will let rfc3484 bit to select the source address
- in the last case, rfc3484bis handles the full retrial process,=20
determines when a retrial is needed and selects the src address for it

>> - a second approach would be similar to the current case where the
>>   app does not select the src address. In this case, the rfc3484bis
>>   src address selection mechanism would need to use a different
>>   src address each time the apps retries.
>
> Yes, this is absolutely essential because consistently selecting a=20
> non-working address is the worst possible outcome.
>

right, and always retrying using different dst address but always the=20
same non-working src address seems a bad scenario

>>   In this case the responsible for retrying is still the app, and
>>   the app needs to be informed that it needs to retry several
>>   times with the same dst address, so that the rfc3484bis would
>>   use different src address for this dst address. In order to
>>   do this we could define an notification at the api level
>>   to allow rfc3484bis mechanisms to inform the app that no more
>>   src addresses are available to retry with and that we will be
>>   recycling to ones that have already been tried (so that the
>>   app can give up or use a different dst address)
>
> Also API + application changes...
>

right

>> - a third approach would be to allow rfc3484bis to handle
>>   retrials itself when the src address is left unspecified by the app
>>   In this case, when an app tries to open a socket with an
>>   unspecified src address, rfc3484bis would try to send packets with
>>   different src addresses until it finds one that it is working.
>
> Right.
>
> And the next logical step is to do the same thing for the destination=20=

> address.
>

but this would imply too much changes at this stage....
i mean, you can do this by connecting by name, in which case, there=20
shouldn't be much problem, but if you want to support this when=20
connecting by address, then you will need something like the shim to be=20=

negotiated upfront, before the communication even starts. this also=20
requires support from both ends. I don't think this is the goal of=20
rfc3484 bis, but rather the goal of the extension that we discussed in=20=

the ams meeting about the API on steroids for the shim.

So, i see this as different issues:
-on one hand we have rfc3484bis, that provides guidance to apps about=20
which address pairs to use, and
- tries to select a reasonable src address when the app leave it=20
unpsecified and perhaps,
- it retries using different src addresses

while otoh, we have shim+API on steroids, that given a ulid pair (or an=20=

dst ulid) it attempts to establish a connection using perhaps=20
alternative locators, in a transparent fashion to the app. In addition,=20=

the shim through this API on steroids, it can inform that there are not=20=

working locators for this dst ulid, and that it may make sense to try=20
with an alternative dst ulid (because the shim knows that there are=20
working locators for this ulid). Perhaps, we could even allow the shim=20=

to provide an enhanced connect by name service

but i would suggest to do this separation about what is done by=20
rfc3484bis and what is done by the shim + API on steroids

>>   the main difficulty is how rfc3484bis can determine that
>>   a src address is working
>
> For TCP it's simple: connect() fails =3D retry with a different =
address.
>
> For UDP a packet coming back with src addr as dest addr, src port as=20=

> dst port etc is a reasonable indication that things are going well.
>

right, but for this second case, this may lead to erroneous=20
conclusions, which may be a big problem, since rfc3484 bis would be=20
stubbornly using a given src address while this may not be working (for=20=

that particular app)

>> Now, this third approach is at best very debatable.
>> I think that the first two approaches make sense and that it would be=20=

>> useful to incoporate information about incoming address pairs as a=20
>> hint to select outgoing address pairs that are working.
>
> Is RFC 3484 ipv6 wg domain? In that case I think we may want to see=20
> what that wg has to say.

right. the approach proposed in ams was for me to write a memo=20
describing the limitations of rfc3484 for multihoming support and a=20
descriptions of the possible changes to rfc3484 to produce rfc3484 bis=20=

that deals with this.

i am on it, and i was thinking to include the points that i mention=20
above, that i why this feedback is so important to me

> I suspect they'll be less than thrilled with API/applications.
>

> [suppressing shim header]
>
>>> As I've explained before: this can be exceedingly simple. We just=20
>>> need signalling message, or a field in an existing signalling=20
>>> message, so that a host can tell its correspondent that it doesn't=20=

>>> want to see the shim header for packets with rewritten addresses=20
>>> within this context. If the sender simply honors this option then=20
>>> we're done in the base spec.
>
>> i guess that the point is that we don't want to include this bit=20
>> unless we know that we know how to make this extension work in a=20
>> simple way
>
> :-)
>
>>> How about this: I'll write the draft about how this would work in=20
>>> practice (i.e., when a host can demultiplex without the shim header)=20=

>>> and after that we make the final decision?
>
>> this works perfectly for me
>
> Great.
>
>> (also i would be glad to work in the draft with you if you want)
>
> Ok I'll contact you when I have my initial thoughts laid out.
>
>>>>>>      * Adopt HIP parameter format for options; HIP parameter=20
>>>>>> format
>>>>>>        defines length in bytes but guarantees 64-bit alignment.
>>>
>
>>>>> I don't want this alignment. It wastes space, it's an=20
>>>>> implementation headache and it buys us nothing.
>
>>>> i think that this is a small price to pay to allow future=20
>>>> convergence with hip that is anther protocol somehow related with=20=

>>>> shim6
>
>>> No, I don't see how this makes sense. It just makes the decision=20
>>> making much more complex as the needs of two different mechanisms=20
>>> must be aligned first.
>
>> not sure i understand what you mean here...
>> in the meeting we agreed that this is basically all that was to be=20
>> done in order to provide hip compatibility (no other consderations=20
>> will be made w.r.t. hip compatibility afaiu)
>
> The problem here is that now the protocol layout is limited by the=20
> requirements of both HIP and shim, and if either of these requires=20
> some change, there must be extensive negotiations to maintain=20
> compatibility.
>

no, we agreed that this will be the only effort to provide hip-shim=20
compatibility. no common option type name space nor similar will be=20
used

regards, marcelo

Delivery-date: Fri, 28 Oct 2005 08:52:32 +0000
Date: Thu, 27 Oct 2005 10:56:56 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Comments on REAP draft

Jari Arkko wrote:

>> I don't understand the comment text that says:
>>    The REAP design allows performing both failure detection and address
>>    pair exploration in the same sequence of messages, without a need to
>>    designate a specific point when the current address pair is declared
>>    inoperational and the search for a new pair begins.
>> It seems like the timout event that triggers a message with Y=no is quite
>> different than the one that triggers a message with Y=yes. And the one 
>> that
>> causes a message with Y=no is the point at which the current address pair
>> has been declared inoperational. So I'm not convinced it is helpful to
>> be able to have the "FBD keepalive" (the payload reception report) and
>> the event reception report in the same shim6 message.
> 
> 
> The Y bit causes indeed different behaviour. We can easily
> define this as a separate message. For the moment I'm thinking
> that there's more common in Y=0 & Y=1 than there's different.

Hmm - I didn't read the text in the draft as being about the Y bit, but 
being an argument that the "payload reception report" and "event 
reception report" being carried as part of the same Probe message.

I agree that having Y=1 and Y=0 in the same message seems useful.

> For instance, it seems useful to carry same information about
> what traffic/probes you have seen. 

I can understand that it is useful to say that you've seen traffic but 
not sent anything back - hence a FBD keepalive (which the draft calls 
payload reception report).
And one needs to be able to provide the probes one has seen.
But I don't see any case when both would be used at the same time.

> It also seems useful (at least
> in thinking some future load-balancing or true multipath
> extensions) to be able to send multiple keepalives.

You mean keepalives for multiple context between the same pair of hosts?
That might be a useful optimization, but to carry those semantics in a 
payload reception report, you'd need to include the actual locator pair 
on which you've received things.

> Finally,
> after short transient failures you may end up receiving the
> peer's keepalive or a payload packet instead of one of the
> explore acks. To me this says that behaviour-wise, we need
> to be able to treat all this information.

Yes, but the semantics are quite different between {keepalive, payload} 
and explore.

The first indicates that the receive path is working, but nothing about 
transmit. The explore has explicit information about what's working.

Hence I think it is actually easier to understand if the keepalive is 
separated from the explore.

>> I can't find one. Should this happen it would be an indication that
>> payloads continue to be sent as alternate locators are used. In that 
>> case the
>> payload reception report might not contain enough information to tell 
>> which
>> locator pair was used; the locator pair might have switched due to the
>> exploration. So *if* there is a case when payload reception reports 
>> and event
>> reception reports are used at the same time, then the payload reception
>> report needs to include the locator pair(s) on which the payload(s) were
>> received.
> 
> 
> Yes. I don't remember whether I added this to the draft - I
> guess not since you are asking. For NAT purposes it would
> be also necessary to know where packets (including probes)
> are received from.

There is a NAT note about that.
My point is that this applies when multiple locators are in use at the 
same time, for instance if we want to optimize things when we have 
multiple contexts (whether for forked contexts using different locator 
pairs, or contexts for different ULID pairs between the same hosts).

    Erik

Delivery-date: Fri, 28 Oct 2005 08:52:02 +0000
Date: Thu, 27 Oct 2005 11:09:40 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Iljitsch van Beijnum wrote:
> On 20-okt-2005, at 6:54, Erik Nordmark wrote:
> 
>>> 8.  Do not use locator ordering and index references in SHIM6 control
>>>     messages in the initial base spec
> 
> 
>> I'm not sure we really decided that at the Interim meeting. In the  
>> current proto draft the locator preferences are expressed by  assuming 
>> that the locator list is ordered so that the relative  position can be 
>> used in the locator preferences without having to  include all the 
>> locators themselves in order to express the  preferences.
> 
> 
> The advantage of doing it this way is that some messages will be  
> shorter because they only need a few bits as a pointer to a locator  
> rather than the full 16 bytes locator itself.
> 
> However, the disadvantage is that you must always be certain that the  
> locator lists are in sync. In the presence of lost and reordered  
> packets this means a significant extra burden on implementations.
> 
> I don't think the savings in relatively sparse signalling messages is  
> worth the extra complexity.

I made the point in a follow-up mail that you need to worry about the 
complexity in any case.

Here is a contrived example:

A and B setup the context with locators A1, A2 and B1, B2. At least A is 
using CGA.

A gets a new locator (A3) and sends an update message. It doesn't hear 
an ack. Retransmits. Still nothing.

A then sees that the A3 locator has locally failed (e.g., flaky WiFi 
interface), so it wants to send a locator preference update saying 
"don't use A3".

But it hasn't yet seen an ack to the update that introduced A3.

Somehow the protocol needs to deal with this dependency, which adds some 
complexity.

There are two rather different approaches to solve this dependency 
between the multiple updates:
  - use sequence numbers and a window (=1?) for update messages, so that
    the first update will be retransmitted until acked, before the second
    update can be sent.

  - Putting the newest information in a single update message and start
    sending that one. Thus including both a new locator list (which
    includes A1, A2, A3) and a preference option (which says "don't use
    A3"). This is then retransmitted until ACKed.

   Erik

Delivery-date: Thu, 27 Oct 2005 22:21:09 +0000
Date: Fri, 28 Oct 2005 08:19:39 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-proto-02.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           : Level 3 multihoming shim protocol
         Author(s)       : E. Nordmark
         Filename        : draft-ietf-shim6-proto-02.txt
         Pages           : 64
         Date            : 2005-10-27

The SHIM6 working group is exploring a layer 3 shim approach for
    providing locator agility below the transport protocols, so that
    multihoming can be provided for IPv6 with failover and load spreading
    properties, without assuming that a multihomed site will have a
    provider independent IPv6 address prefix which is announced in the
    global IPv6 routing table.  The hosts in a site which has multiple
    provider allocated IPv6 address prefixes, will use the shim6 protocol
    specified in this document to setup state with peer hosts, so that
    the state can later be used to failover to a different locator pair,
    should the original one stop working.

    This document picks a particular approach to such a protocol and
    tries to flush out a bunch of details, with the hope that the WG can
    better understand the details in this proposal as well as discovering
    and understanding alternative designs that might be better.  Thus
    this proposal is my no means cast in stone as the direction; quite to
    the contrary it is a depth first exploration of the design space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-02.txt

Delivery-date: Thu, 27 Oct 2005 19:37:46 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 21:37:25 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-okt-2005, at 18:17, marcelo bagnulo braun wrote:

>> It's important that the wg participants that weren't at the  
>> interim meeting determine the merit of all of these points  
>> themselves so the wg can come to rough consensus rather than just  
>> say "well most people that were in Amsterdam agreed so it must be  
>> the right decision".

> absolutely agree

> but we do agree that most people that were in amsterdam agreed on  
> this points, right?

I assume the people in Amsterdam agreed if they didn't say anything  
to the contrary...

>> What RFC does is two things:

>> 1. select source and destination addresses
>> 2. tell application programmers to cycle through all destination  
>> addresses

> kind of agree...
> i would say that rfc3484 does:
> - it passes an ordered list of destiantion addresses to the app and  
> requires that the app should cycle through all of them until finds  
> one that is reachable
> - it selects a source address for a given destiantion address when  
> the app does not select one

Actually, looking over the RFC very quickly, it doesn't look like RFC  
3484 requires applications to cycle through all available  
(destination) addresses.

>> Most IPv4 applications don't cycle through all destination  
>> addresses, and a significant number of IPv6 applications doesn't  
>> either. I don't see applications cycle through all source/dest  
>> pairs because that's very hard to do right.

> not really understand what is the part that you think it is hard....

Specifying an address with bind() is of course not problematic. The  
trouble is maintaining an up to date list of available addresses in  
the system. Since this list is subject to change applications would  
have to query all available addresses prior to any TCP session  
establishments and the like. Also, when the application has this list  
of addresses, it somehow needs to go back to the system to have RFC  
3484 policies applied to the source/dest pairs.

> I think we could have 3 approaches (which can be complementary i.e.  
> does not have to be one or the other)
> - first approach is to let the app take care of everything
>   i.e. inform the app about all src and dst address and let
>   the app try all the possible combinations.
>   This is the minimum change to rfc3484 bis, i.e. state that
>   apps SHOULD retry with all possible src,dst pairs
>   A possible optimization for this, would be that the rfc3484
>   delivers an ordered list of address pairs (similar than current
>   rfc3484 delivers a ordered list of dst address, the rfc3484bis
>   would deliver to the app an ordered list of address pairs (based
>   on rules for prefering one address pair over the other)
>   [an alternative to this that would be more compatible with current
>   rfc3484 would that for a given dst address, rfc3484bis would
>   provide an ordered list or src addresses for this dst address]

I suppose this is possible although I don't find it very desireable.

If applications have to be changed anyway, why not come up with an  
API that REALLY solves all of this?

> - a second approach would be similar to the current case where the
>   app does not select the src address. In this case, the rfc3484bis
>   src address selection mechanism would need to use a different
>   src address each time the apps retries.

Yes, this is absolutely essential because consistently selecting a  
non-working address is the worst possible outcome.

>   In this case the responsible for retrying is still the app, and
>   the app needs to be informed that it needs to retry several
>   times with the same dst address, so that the rfc3484bis would
>   use different src address for this dst address. In order to
>   do this we could define an notification at the api level
>   to allow rfc3484bis mechanisms to inform the app that no more
>   src addresses are available to retry with and that we will be
>   recycling to ones that have already been tried (so that the
>   app can give up or use a different dst address)

Also API + application changes...

> - a third approach would be to allow rfc3484bis to handle
>   retrials itself when the src address is left unspecified by the app
>   In this case, when an app tries to open a socket with an
>   unspecified src address, rfc3484bis would try to send packets with
>   different src addresses until it finds one that it is working.

Right.

And the next logical step is to do the same thing for the destination  
address.

>   the main difficulty is how rfc3484bis can determine that
>   a src address is working

For TCP it's simple: connect() fails = retry with a different address.

For UDP a packet coming back with src addr as dest addr, src port as  
dst port etc is a reasonable indication that things are going well.

> Now, this third approach is at best very debatable.
> I think that the first two approaches make sense and that it would  
> be useful to incoporate information about incoming address pairs as  
> a hint to select outgoing address pairs that are working.

Is RFC 3484 ipv6 wg domain? In that case I think we may want to see  
what that wg has to say. I suspect they'll be less than thrilled with  
API/applications.

[suppressing shim header]

>> As I've explained before: this can be exceedingly simple. We just  
>> need signalling message, or a field in an existing signalling  
>> message, so that a host can tell its correspondent that it doesn't  
>> want to see the shim header for packets with rewritten addresses  
>> within this context. If the sender simply honors this option then  
>> we're done in the base spec.

> i guess that the point is that we don't want to include this bit  
> unless we know that we know how to make this extension work in a  
> simple way

:-)

>> How about this: I'll write the draft about how this would work in  
>> practice (i.e., when a host can demultiplex without the shim  
>> header) and after that we make the final decision?

> this works perfectly for me

Great.

> (also i would be glad to work in the draft with you if you want)

Ok I'll contact you when I have my initial thoughts laid out.

>>>>>      * Adopt HIP parameter format for options; HIP parameter  
>>>>> format
>>>>>        defines length in bytes but guarantees 64-bit alignment.
>>

>>>> I don't want this alignment. It wastes space, it's an  
>>>> implementation headache and it buys us nothing.

>>> i think that this is a small price to pay to allow future  
>>> convergence with hip that is anther protocol somehow related with  
>>> shim6

>> No, I don't see how this makes sense. It just makes the decision  
>> making much more complex as the needs of two different mechanisms  
>> must be aligned first.

> not sure i understand what you mean here...
> in the meeting we agreed that this is basically all that was to be  
> done in order to provide hip compatibility (no other consderations  
> will be made w.r.t. hip compatibility afaiu)

The problem here is that now the protocol layout is limited by the  
requirements of both HIP and shim, and if either of these requires  
some change, there must be extensive negotiations to maintain  
compatibility.

I think compatibility with regard to how the two work together is  
much more important than sharing the same basic header format.

>>  This means the context id must be carried along everywhere.

> not sure what you mean by everywhere...
> packets do you mean?

Everywhere in the IP stack.

>>  One place where this is inconvenient is between the application,  
>> that specifies certain ToS requirements, and the shim. The  
>> transport protocol that sits in the middle must now somehow  
>> "color" all packets with the right context information so the shim  
>> knows what to do with the packet. IIRC there are also signalling  
>> complexities.

> right but this is what it seems that apps want, right? the  
> capability of selecting the locator pair to be used for carrying  
> the traffic (at least this is what i understood this was all about)

Wouldn't it make more sense to do this by selecting ULIDs rather than  
by selecting locators? This has the added advantage that it also  
works regardless of whether the shim is available.

> i think that 10 sec was just a value that was somehow appropriate..  
> i don't have a problem with 15 or 20 secs neither...

I have no problem with 10 as long as this doesn't require sending  
packets every 3 seconds, and I don't see why it would have to.

Delivery-date: Thu, 27 Oct 2005 19:09:28 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Simplified REAP description
Date: Thu, 27 Oct 2005 21:08:29 +0200
To: Erik Nordmark <[email-masked]>

On 27-okt-2005, at 18:44, Erik Nordmark wrote:

> Receiving a packet with iseeyou=yes
> -----------------------------------

> If this is a "payload reception report", then it is just a FBD  
> keepalive and
> is handled as any shim6 control packet above (resetting timers).

> If it is an "event reception report", it indicates that we can  
> terminate the
> explore phase.
> If the host has not yet sent a "iseeyou=yes" event report, it needs to
> send one in response to this packet.

Now suppose:

A1 ----> B1  (data)
A1 <---- B1  (data)
A1 ---|  B1  (data, failure)
              (timeout)
A1 <---- B1  (icu=0)
A1 ---|  B1  (icu=1)
A2 <---- B1  (icu=1, B hasn't timed out from the last message by A)
A1 ----> B2  (icu=1)

Both now think that the other end can see them but this isn't  
necessarily true because the icu=1 doesn't necessarily apply to the  
last packet sent by the other side. For instance:

A1 ----> B1  (data)
A1 <---- B1  (data)
A1 ---|  B1  (data, failure)
              (timeout)
A1 <---- B1  (icu=0)
A1 ---|  B1  (icu=1)
A2 <---- B1  (icu=0)
A1 ----> B2  (icu=1)
A2  |--- B1  (icu=1, random packet loss on otherwise working link)
A2 ---|  B2  (icu=1, ingress filtering)
A2 <---- B2  (icu=1)

A will now think that A2->B2 works, which isn't true.

Delivery-date: Thu, 27 Oct 2005 16:45:34 +0000
Date: Thu, 27 Oct 2005 09:44:49 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: Simplified REAP description

I tried to describe REAP without resorting to a state machine 
description (based on my understanding from the message exchanges in the 
draft) and this description seems a lot simpler than the state machine 
(which could very well be due to me not understanding the state machine).

    Erik

----

First we have the FBD logic, which is basically that when a host receives
a payload packet and the FBD timer isn't running, it sets a 3 second timer.
If it sends any packet (payload, or shim6 control packet) then this timer
is cleared. Should the timer fire, it sends a FBD keepalive (called payload
reception in REAP).

Thus reception of a FBD keepalive will not by itself cause the sending
of a FBD keepalive.

The assumptions is that we have things that trigger going into an explore
phase. The triggers are:
  - sending a packet and not receiving anything (payload, keepalive, or
    other shim6 control packet) within 10 seconds
  - receving a REAP Probe message with iseeyou=no
  - what there is a local indication that a local locator is no longer 
usable
    (in that case it would make sense to also tell the peer to not even try
    that locator, e.g. somehow include the semantics of a preference 
option?)

Once the context has entered the explore phase, it continues to explore
until it finds a working locator pair, i.e. until it receives a REAP
probe with iseeyou=yes.
The only time it would abandon the explore is when the context is garbage
collected e.g. due to it not being used by a ULP any more.

With this approach, the rules for handling the complete protocol
becomes something like this.

Receiving a payload packet
--------------------------

If the keepalive timer isn't running, then start it.
Stop the send timer (if it was running).

Receiving a keepalive or other shim6 control packet
---------------------------------------------------

Stop the send timer (if it was running).

Sending a packet (payload, keepalive, or other control packet)
--------------------------------------------------------------

Stop the keepalive timer (if it was running).

Only for a payload packet:
	If the send timer isn't already running, start it.

Timeout due to having received but not sent
-------------------------------------------

When the keepalive timer fires (after 3 seconds),
we send a FBD keepalive (a payload reception report).

Timeout due to having sent but not received
-------------------------------------------

When the send timer fires (after 10 seconds), we enter the explore phase
and start exploring by sending an event with iseeyou=no.
(We don't do this if we are already in the explore phase.)

Receiving a packet with iseeyou=no
----------------------------------

If the context is already in explore phase, ignore the packet.
(From a congestion control perspective, it is presumably ok to use the
reception of such a packet as a "self-clock" and use it to send another 
Probe
packet, independent of the binary exponential backoff for Probe packets sent
when no Probe was received.)

Otherwise, enter the explore phase and send the first Probe.

Receiving a packet with iseeyou=yes
-----------------------------------

If this is a "payload reception report", then it is just a FBD keepalive and
is handled as any shim6 control packet above (resetting timers).

If it is an "event reception report", it indicates that we can terminate 
the
explore phase.
If the host has not yet sent a "iseeyou=yes" event report, it needs to
send one in response to this packet.

---

Delivery-date: Thu, 27 Oct 2005 16:17:56 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 18:17:26 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 27/10/2005, a las 17:08, Iljitsch van Beijnum escribi=F3:

> On 27-okt-2005, at 15:29, marcelo bagnulo braun wrote:
>
>>> I don't think "decisions" is the right word here... These are more=20=

>>> like suggestions by the chairs.
>
>> sorry, but i disagree here.
>> The points below were accepted by most of the people in the room (i=20=

>> certainly accepted most of them)
>
> It's important that the wg participants that weren't at the interim=20
> meeting determine the merit of all of these points themselves so the=20=

> wg can come to rough consensus rather than just say "well most people=20=

> that were in Amsterdam agreed so it must be the right decision".
>

absolutely agree

but we do agree that most people that were in amsterdam agreed on this=20=

points, right?

>>> The real point is what happens when the address pair selected by=20
>>> either the application or RFC 3484 doesn't work. How do we handle=20
>>> this case?
>
>> the idea, (and i think this is was this decision point is about) is=20=

>> that we need an update to rfc 3484 to deal with this.
>
> What RFC does is two things:
>
> 1. select source and destination addresses
> 2. tell application programmers to cycle through all destination=20
> addresses
>

kind of agree...
i would say that rfc3484 does:
- it passes an ordered list of destiantion addresses to the app and=20
requires that the app should cycle through all of them until finds one=20=

that is reachable
- it selects a source address for a given destiantion address when the=20=

app does not select one

> Any modifications to these won't help if an application, with help=20
> from RFC 3484 or its successor, selects an address pair that isn't=20
> reachable and then DOESN'T cycle through all source/destination=20
> combinations.

well, first of all, rfc3484 should state that the app should cycle not=20=

only through all the destination addresses but through all possible=20
pairs of source destiantion address pairs available.

This is the minimum change that rfc3484 would require

of course i agree that we should do better and try to help with apps=20
that don't cycle through all the possible address pairs

>
> Most IPv4 applications don't cycle through all destination addresses,=20=

> and a significant number of IPv6 applications doesn't either. I don't=20=

> see applications cycle through all source/dest pairs because that's=20
> very hard to do right.
>

not really understand what is the part that you think it is hard....
i can think of soem difficulties, but i would like to see if we are=20
considering the same problems here...

> So either we have three choices:
>
> 1. adopt the "second shim" to do this for the application
> 2. make it possible to repair the situation where there is no=20
> reachability between the ULIDs from the start.
> 3. update RFC 3484 and wait for all applications to be updated
>
> I believe 3. won't work in practice and if it did, it would be a huge=20=

> duplication of effort as all applications would have to implement the=20=

> same functionality. Remember that we chose to make the shim such that=20=

> unmodified applications can benefit from it.
>

Ok, let me explain how i see it:

I think we could have 3 approaches (which can be complementary i.e.=20
does not have to be one or the other)
- first approach is to let the app take care of everything
   i.e. inform the app about all src and dst address and let
   the app try all the possible combinations.
   This is the minimum change to rfc3484 bis, i.e. state that
   apps SHOULD retry with all possible src,dst pairs
   A possible optimization for this, would be that the rfc3484
   delivers an ordered list of address pairs (similar than current
   rfc3484 delivers a ordered list of dst address, the rfc3484bis
   would deliver to the app an ordered list of address pairs (based
   on rules for prefering one address pair over the other)
   [an alternative to this that would be more compatible with current
   rfc3484 would that for a given dst address, rfc3484bis would
   provide an ordered list or src addresses for this dst address]

- a second approach would be similar to the current case where the
   app does not select the src address. In this case, the rfc3484bis
   src address selection mechanism would need to use a different
   src address each time the apps retries.
   In this case the responsible for retrying is still the app, and
   the app needs to be informed that it needs to retry several
   times with the same dst address, so that the rfc3484bis would
   use different src address for this dst address. In order to
   do this we could define an notification at the api level
   to allow rfc3484bis mechanisms to inform the app that no more
   src addresses are available to retry with and that we will be
   recycling to ones that have already been tried (so that the
   app can give up or use a different dst address)

- a third approach would be to allow rfc3484bis to handle
   retrials itself when the src address is left unspecified by the app
   In this case, when an app tries to open a socket with an
   unspecified src address, rfc3484bis would try to send packets with
   different src addresses until it finds one that it is working.
   the main difficulty is how rfc3484bis can determine that
   a src address is working (in the previous approaches, this was
   left up to the app, which knew when a address pair was working
   and when it wasn't, it retried to send the packet again)
   In this case, the goal would be to leave rfc3484bis to determine
   when a src address (or an address pair) is working.
   I guess that if we assume that rfc3484bis will only handle
   bidirectional paths, we can assume that if we receive a packet
   with src address IP1 and dst address IP2m then we can say that
   the address pair with src=3DIP2 and dst=3DIP1 is working as an
   outgoing address pair.
   Using this, rfc3484bis can cache information about address pairs
   contained in received packets, to determine address pairs that
   are working. In this case, rfc3484bis would send a packet using
   a given address pair, and if no packets are received from this
   address pair in a given period, it could retry to send the packet
   using a different address pair until it finds one that
   receives traffic back, or it gives up

Now, this third approach is at best very debatable.
I think that the first two approaches make sense and that it would be=20
useful to incoporate information about incoming address pairs as a hint=20=

to select outgoing address pairs that are working.

>>> I have no problem with a shim header for demultiplexing in cases=20
>>> where demultiplexing would otherwise be very hard or impossible. For=20=

>>> instance, in the case of several extension headers, an explicit shim=20=

>>> header makes it possible to indicate which headers see modified=20
>>> addresses and which headers see unmodified addresses unambiguously.
>
>>> However, I think it's a very bad idea to have a shim header in EVERY=20=

>>> packet with rewritten addresses, because there are cases where the=20=

>>> shim context can be determined from information that's already in=20
>>> the packet unambiguously so an extra header is unnecessary.
>
> [...]
>
>> this is the point of debate: whether this extension should be=20
>> mandatory in the base spec or not.
>
>> my opinion about this, is that this would be indeed quite complex.
>
> As I've explained before: this can be exceedingly simple. We just need=20=

> signalling message, or a field in an existing signalling message, so=20=

> that a host can tell its correspondent that it doesn't want to see the=20=

> shim header for packets with rewritten addresses within this context.=20=

> If the sender simply honors this option then we're done in the base=20
> spec.
>

i guess that the point is that we don't want to include this bit unless=20=

we know that we know how to make this extension work in a simple way

> Deciding when a host can safely set this option is more complex of=20
> course, but THAT part can be an experimental extension. (I'll write a=20=

> draft shortly.) However, it's essential that the capability to=20
> suppress the shim header is in there from the start, or implementing=20=

> the logic to enable this capability will be so hard to get off the=20
> ground (then both ends would need to be updated rather than just the=20=

> receiver) that probably nobody is going to bother etc etc.
>
>> I mean i like the idea but i am afraid that when we try to define the=20=

>> details, the result will be complex. If not i would certainly support=20=

>> this
>
> How about this: I'll write the draft about how this would work in=20
> practice (i.e., when a host can demultiplex without the shim header)=20=

> and after that we make the final decision?
>

this works perfectly for me

(also i would be glad to work in the draft with you if you want)

> That would be after Vancouver, though.
>
>>>> 4.  Use a 32 bit context field with no checksum, and 15 reserved=20
>>>> bits and a
>>>>     1 bit flag to indicate control / payload. Note potential DOS=20
>>>> risks
>
>>> If we know there are risks today, maybe it makes more sense to make=20=

>>> the tag variable size (to be negotiated between the peers) rather=20
>>> than fixed?
>
>> what about making it fixed of 47 bits from the start?
>
> Then there is no room for extensions, and some implementations may be=20=

> more confortable with 32 bit math.
>
>>>>      * Adopt HIP parameter format for options; HIP parameter format
>>>>        defines length in bytes but guarantees 64-bit alignment.
>
>>> I don't want this alignment. It wastes space, it's an implementation=20=

>>> headache and it buys us nothing.
>
>> i think that this is a small price to pay to allow future convergence=20=

>> with hip that is anther protocol somehow related with shim6
>
> No, I don't see how this makes sense. It just makes the decision=20
> making much more complex as the needs of two different mechanisms must=20=

> be aligned first.
>

not sure i understand what you mean here...
in the meeting we agreed that this is basically all that was to be done=20=

in order to provide hip compatibility (no other consderations will be=20
made w.r.t. hip compatibility afaiu)

>>> Forking is a bad idea, it increases the complexity of the shim=20
>>> manifold while pretty much the same functionality can also be=20
>>> provided in a different way.
>
>> i guess it depends on how you handle it... i mean for me, i see it=20
>> just as multiple contexts with the same ulid pair, but with different=20=

>> context tag. In this view, it doesn't seems very complex, it is just=20=

>> multiple contexts..., am i missing something?
>
> With forking, a context is no longer uniquely identified by a ULID=20
> pair.

right, ulid pair plus context tag defines the context

>  This means the context id must be carried along everywhere.

not sure what you mean by everywhere...
packets do you mean?

>  One place where this is inconvenient is between the application, that=20=

> specifies certain ToS requirements, and the shim. The transport=20
> protocol that sits in the middle must now somehow "color" all packets=20=

> with the right context information so the shim knows what to do with=20=

> the packet. IIRC there are also signalling complexities.
>

right but this is what it seems that apps want, right? the capability=20
of selecting the locator pair to be used for carrying the traffic (at=20
least this is what i understood this was all about)

>>>> 18. Use a statically specified in the initial protocol=20
>>>> specification of
>>>>     (10) seconds.
>
>>> This means that senders must transmit something (data, keepalive)=20
>>> every 10 seconds, right? So the receiver needs to wait a bit LONGER=20=

>>> than 10 seconds to time out.
>
>> as i recall it, 10 seconds was the time of 3 packets i.e. a node is=20=

>> expected to send packets every 3 seconds, so if 3 packets are=20
>> missing, then we have a problem detected.
>
> I think every 3 seconds is excessive. So in my draft I just wait 12 -=20=

> 15 seconds at the receiver (10 seconds that the sender uses + margin=20=

> for RTT and jitter), and then initiate the full reachability=20
> exploration. This will first do a packet with the currently used=20
> address pair but after a very short timeout it will start to explore=20=

> alternate address pairs.
>
> This means the full exploration may be triggered when omly two packets=20=

> are dropped, which is a bit aggressive, but on the other hand it means=20=

> only an FBD keepalive every 10 seconds rather than every 3 seconds so=20=

> I think this makes sense.
>

i think that 10 sec was just a value that was somehow appropriate.. i=20
don't have a problem with 15 or 20 secs neither...

regards, marcelo

Delivery-date: Thu, 27 Oct 2005 15:09:02 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 17:08:22 +0200
To: marcelo bagnulo braun <[email-masked]>

On 27-okt-2005, at 15:29, marcelo bagnulo braun wrote:

>> I don't think "decisions" is the right word here... These are more  
>> like suggestions by the chairs.

> sorry, but i disagree here.
> The points below were accepted by most of the people in the room (i  
> certainly accepted most of them)

It's important that the wg participants that weren't at the interim  
meeting determine the merit of all of these points themselves so the  
wg can come to rough consensus rather than just say "well most people  
that were in Amsterdam agreed so it must be the right decision".

>> The real point is what happens when the address pair selected by  
>> either the application or RFC 3484 doesn't work. How do we handle  
>> this case?

> the idea, (and i think this is was this decision point is about) is  
> that we need an update to rfc 3484 to deal with this.

What RFC does is two things:

1. select source and destination addresses
2. tell application programmers to cycle through all destination  
addresses

Any modifications to these won't help if an application, with help  
from RFC 3484 or its successor, selects an address pair that isn't  
reachable and then DOESN'T cycle through all source/destination  
combinations.

Most IPv4 applications don't cycle through all destination addresses,  
and a significant number of IPv6 applications doesn't either. I don't  
see applications cycle through all source/dest pairs because that's  
very hard to do right.

So either we have three choices:

1. adopt the "second shim" to do this for the application
2. make it possible to repair the situation where there is no  
reachability between the ULIDs from the start.
3. update RFC 3484 and wait for all applications to be updated

I believe 3. won't work in practice and if it did, it would be a huge  
duplication of effort as all applications would have to implement the  
same functionality. Remember that we chose to make the shim such that  
unmodified applications can benefit from it.

>> I have no problem with a shim header for demultiplexing in cases  
>> where demultiplexing would otherwise be very hard or impossible.  
>> For instance, in the case of several extension headers, an  
>> explicit shim header makes it possible to indicate which headers  
>> see modified addresses and which headers see unmodified addresses  
>> unambiguously.

>> However, I think it's a very bad idea to have a shim header in  
>> EVERY packet with rewritten addresses, because there are cases  
>> where the shim context can be determined from information that's  
>> already in the packet unambiguously so an extra header is  
>> unnecessary.

[...]

> this is the point of debate: whether this extension should be  
> mandatory in the base spec or not.

> my opinion about this, is that this would be indeed quite complex.

As I've explained before: this can be exceedingly simple. We just  
need signalling message, or a field in an existing signalling  
message, so that a host can tell its correspondent that it doesn't  
want to see the shim header for packets with rewritten addresses  
within this context. If the sender simply honors this option then  
we're done in the base spec.

Deciding when a host can safely set this option is more complex of  
course, but THAT part can be an experimental extension. (I'll write a  
draft shortly.) However, it's essential that the capability to  
suppress the shim header is in there from the start, or implementing  
the logic to enable this capability will be so hard to get off the  
ground (then both ends would need to be updated rather than just the  
receiver) that probably nobody is going to bother etc etc.

> I mean i like the idea but i am afraid that when we try to define  
> the details, the result will be complex. If not i would certainly  
> support this

How about this: I'll write the draft about how this would work in  
practice (i.e., when a host can demultiplex without the shim header)  
and after that we make the final decision?

That would be after Vancouver, though.

>>> 4.  Use a 32 bit context field with no checksum, and 15 reserved  
>>> bits and a
>>>     1 bit flag to indicate control / payload. Note potential DOS  
>>> risks

>> If we know there are risks today, maybe it makes more sense to  
>> make the tag variable size (to be negotiated between the peers)  
>> rather than fixed?

> what about making it fixed of 47 bits from the start?

Then there is no room for extensions, and some implementations may be  
more confortable with 32 bit math.

>>>      * Adopt HIP parameter format for options; HIP parameter format
>>>        defines length in bytes but guarantees 64-bit alignment.

>> I don't want this alignment. It wastes space, it's an  
>> implementation headache and it buys us nothing.

> i think that this is a small price to pay to allow future  
> convergence with hip that is anther protocol somehow related with  
> shim6

No, I don't see how this makes sense. It just makes the decision  
making much more complex as the needs of two different mechanisms  
must be aligned first.

>> Forking is a bad idea, it increases the complexity of the shim  
>> manifold while pretty much the same functionality can also be  
>> provided in a different way.

> i guess it depends on how you handle it... i mean for me, i see it  
> just as multiple contexts with the same ulid pair, but with  
> different context tag. In this view, it doesn't seems very complex,  
> it is just multiple contexts..., am i missing something?

With forking, a context is no longer uniquely identified by a ULID  
pair. This means the context id must be carried along everywhere. One  
place where this is inconvenient is between the application, that  
specifies certain ToS requirements, and the shim. The transport  
protocol that sits in the middle must now somehow "color" all packets  
with the right context information so the shim knows what to do with  
the packet. IIRC there are also signalling complexities.

>>> 18. Use a statically specified in the initial protocol  
>>> specification of
>>>     (10) seconds.

>> This means that senders must transmit something (data, keepalive)  
>> every 10 seconds, right? So the receiver needs to wait a bit  
>> LONGER than 10 seconds to time out.

> as i recall it, 10 seconds was the time of 3 packets i.e. a node is  
> expected to send packets every 3 seconds, so if 3 packets are  
> missing, then we have a problem detected.

I think every 3 seconds is excessive. So in my draft I just wait 12 -  
15 seconds at the receiver (10 seconds that the sender uses + margin  
for RTT and jitter), and then initiate the full reachability  
exploration. This will first do a packet with the currently used  
address pair but after a very short timeout it will start to explore  
alternate address pairs.

This means the full exploration may be triggered when omly two  
packets are dropped, which is a bit aggressive, but on the other hand  
it means only an FBD keepalive every 10 seconds rather than every 3  
seconds so I think this makes sense.

>> Note that the tradeoff is:

>> < 240 seconds: we MUST repair the problem before TCP times out
>> > 180 seconds: wait for BGP (90 - 180 second timeout) to fix the  
>> problem
>> < 90 & > 40 seconds: don't wait for BGP, but do wait for OSPF (40  
>> second timeout) to fix the problem
>> < 40 seconds: don't wait for OSPF

> are you suggesting that we change this to a higher value? i think  
> that this was one proposal, and i think that it can be easily  
> changed...

With one FBD packet per 10 seconds I don't have a problem. A quick  
scan of RFC 1889 seems to indicate that RTP stays below 10 seconds  
for its return traffic in typical cases so that shouldn't be an issue.

Delivery-date: Thu, 27 Oct 2005 13:29:30 +0000
Cc: [email-masked], Geoff Huston <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 15:29:24 +0200
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

El 27/10/2005, a las 14:42, Iljitsch van Beijnum escribi=F3:

> On 19-okt-2005, at 6:11, Geoff Huston wrote:
>
>> The following is a list of SHIM6 design decisions
>
> I don't think "decisions" is the right word here... These are more=20
> like suggestions by the chairs.
>

sorry, but i disagree here.
The points below were accepted by most of the people in the room (i=20
certainly accepted most of them)

(perhaps there is some points where there may be some misunderstanding=20=

on the final outcome, like the point about the preferences that Erik=20
brought up (my understanding was similar to Erik's one) but this is a=20
natural problem when summarizing long discussions as the ones we had,=20
and they are  being clarified through this discussion)

>> 1.  The specification for initial contact will use RFC3484, as=20
>> modified by
>>     this draft in terms of source address ordering.
>
> Well, all IPv6 hosts are expected to use RFC 3484 address selection,=20=

> nothing new there. In fact, we have to break RFC 3484 from time to=20
> time because otherwise we'd be selecting non-working addresses.
>
> The real point is what happens when the address pair selected by=20
> either the application or RFC 3484 doesn't work. How do we handle this=20=

> case?
>

the idea, (and i think this is was this decision point is about) is=20
that we need an update to rfc 3484 to deal with this.
i am currently working on a document about this (as we agreed in the=20
meeting) with some proposals of how to update rfc3484 to deal with=20
this.

>> 2.  Use an 8 byte IP SHIM6 header in the base protocol specification=20=

>> for
>>     packets that require specific SHIM6 processing by the receiver,=20=

>> and
>>     allow optimizations on this, including that of a zero-length=20
>> header, to
>>     be an experimental protocol extension.
>
> I have no problem with a shim header for demultiplexing in cases where=20=

> demultiplexing would otherwise be very hard or impossible. For=20
> instance, in the case of several extension headers, an explicit shim=20=

> header makes it possible to indicate which headers see modified=20
> addresses and which headers see unmodified addresses unambiguously.
>
> However, I think it's a very bad idea to have a shim header in EVERY=20=

> packet with rewritten addresses, because there are cases where the=20
> shim context can be determined from information that's already in the=20=

> packet unambiguously so an extra header is unnecessary.
>
> Mandating a shim header first and then optionally allow it to be=20
> suppressed is useless in practice: we need have the capability to have=20=

> the shim header suppressed

so far i think that we all agree

>  as a mandatory part of the inital base spec.
>

this is the point of debate: whether this extension should be mandatory=20=

in the base spec or not.

my opinion about this, is that this would be indeed quite complex. I=20
mean i like the idea but i am afraid that when we try to define the=20
details, the result will be complex. If not i would certainly support=20
this

I think that the best approach is what (i understood that it) was=20
decided in the meeting:
- for now the base spec does not includes this.
- a document is produced to understand what it would take to support=20
this extension. that is a full fleshed proposal of what would be=20
required to do this. (my recall is that you and Pekka? were to produce=20=

this?)

>> 4.  Use a 32 bit context field with no checksum, and 15 reserved bits=20=

>> and a
>>     1 bit flag to indicate control / payload. Note potential DOS =
risks
>
> If we know there are risks today, maybe it makes more sense to make=20
> the tag variable size (to be negotiated between the peers) rather than=20=

> fixed?
>

what about making it fixed of 47 bits from the start?

> Remember, there are no second chances: if we botch the initial packet=20=

> layouts we'll have to live with them for a long time.
>
>>      * Adopt HIP parameter format for options; HIP parameter format
>>        defines length in bytes but guarantees 64-bit alignment.
>
> I don't want this alignment. It wastes space, it's an implementation=20=

> headache and it buys us nothing.
>

i think that this is a small price to pay to allow future convergence=20
with hip that is anther protocol somehow related with shim6

>> 11. Proposed to drop specific mechanism for locator test and response
>
> ???
>
>> 13. [What are privacy requirements for locator lists? Also integrity=20=

>> - this
>>      protocol is currently "in the clear".]
>
> One person's privacy is the next person's debugging nightmare.
>
> There is no privacy in today's multihoming either.
>
>> 14. View forking as a unidirectional context state fork (based on a=20=

>> ULP
>>     signal) that assumes that the forked context state may then use a
>>     different outgoing locator pair.
>
> Forking is a bad idea, it increases the complexity of the shim=20
> manifold while pretty much the same functionality can also be provided=20=

> in a different way.

i guess it depends on how you handle it... i mean for me, i see it just=20=

as multiple contexts with the same ulid pair, but with different=20
context tag. In this view, it doesn't seems very complex, it is just=20
multiple contexts..., am i missing something?

>
>> 16. SHIM6 control message sequence numbers are not needed here.=20
>> [control
>>     messages]
>
> My reachability/failure detection draft has sequence numbers of its=20
> own in the reachability probes.
>

right
locator sets also have the generation number which is a seq number
i guess that the point is that the protocol as a whole does not have=20
seq numbers, like first packet I1 with seq number 1, next packet I2 seq=20=

number 2 and so on...

>> 18. Use a statically specified in the initial protocol specification=20=

>> of
>>     (10) seconds.
>
> This means that senders must transmit something (data, keepalive)=20
> every 10 seconds, right? So the receiver needs to wait a bit LONGER=20
> than 10 seconds to time out.
>

as i recall it, 10 seconds was the time of 3 packets i.e. a node is=20
expected to send packets every 3 seconds, so if 3 packets are missing,=20=

then we have a problem detected.

> Note that the tradeoff is:
>
> < 240 seconds: we MUST repair the problem before TCP times out
> > 180 seconds: wait for BGP (90 - 180 second timeout) to fix the=20
> problem
> < 90 & > 40 seconds: don't wait for BGP, but do wait for OSPF (40=20
> second timeout) to fix the problem
> < 40 seconds: don't wait for OSPF
>

are you suggesting that we change this to a higher value? i think that=20=

this was one proposal, and i think that it can be easily changed...

regards, marcelo

Delivery-date: Thu, 27 Oct 2005 12:46:21 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 14:46:05 +0200
To: Erik Nordmark <[email-masked]>

On 20-okt-2005, at 6:54, Erik Nordmark wrote:

>> 8.  Do not use locator ordering and index references in SHIM6 control
>>     messages in the initial base spec

> I'm not sure we really decided that at the Interim meeting. In the  
> current proto draft the locator preferences are expressed by  
> assuming that the locator list is ordered so that the relative  
> position can be used in the locator preferences without having to  
> include all the locators themselves in order to express the  
> preferences.

The advantage of doing it this way is that some messages will be  
shorter because they only need a few bits as a pointer to a locator  
rather than the full 16 bytes locator itself.

However, the disadvantage is that you must always be certain that the  
locator lists are in sync. In the presence of lost and reordered  
packets this means a significant extra burden on implementations.

I don't think the savings in relatively sparse signalling messages is  
worth the extra complexity.

Delivery-date: Thu, 27 Oct 2005 12:43:08 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 14:42:29 +0200
To: Geoff Huston <[email-masked]>

On 19-okt-2005, at 6:11, Geoff Huston wrote:

> The following is a list of SHIM6 design decisions

I don't think "decisions" is the right word here... These are more  
like suggestions by the chairs.

> 1.  The specification for initial contact will use RFC3484, as  
> modified by
>     this draft in terms of source address ordering.

Well, all IPv6 hosts are expected to use RFC 3484 address selection,  
nothing new there. In fact, we have to break RFC 3484 from time to  
time because otherwise we'd be selecting non-working addresses.

The real point is what happens when the address pair selected by  
either the application or RFC 3484 doesn't work. How do we handle  
this case?

> 2.  Use an 8 byte IP SHIM6 header in the base protocol  
> specification for
>     packets that require specific SHIM6 processing by the receiver,  
> and
>     allow optimizations on this, including that of a zero-length  
> header, to
>     be an experimental protocol extension.

I have no problem with a shim header for demultiplexing in cases  
where demultiplexing would otherwise be very hard or impossible. For  
instance, in the case of several extension headers, an explicit shim  
header makes it possible to indicate which headers see modified  
addresses and which headers see unmodified addresses unambiguously.

However, I think it's a very bad idea to have a shim header in EVERY  
packet with rewritten addresses, because there are cases where the  
shim context can be determined from information that's already in the  
packet unambiguously so an extra header is unnecessary.

Mandating a shim header first and then optionally allow it to be  
suppressed is useless in practice: we need have the capability to  
have the shim header suppressed as a mandatory part of the inital  
base spec.

> 4.  Use a 32 bit context field with no checksum, and 15 reserved  
> bits and a
>     1 bit flag to indicate control / payload. Note potential DOS risks

If we know there are risks today, maybe it makes more sense to make  
the tag variable size (to be negotiated between the peers) rather  
than fixed?

Remember, there are no second chances: if we botch the initial packet  
layouts we'll have to live with them for a long time.

>      * Adopt HIP parameter format for options; HIP parameter format
>        defines length in bytes but guarantees 64-bit alignment.

I don't want this alignment. It wastes space, it's an implementation  
headache and it buys us nothing.

> 11. Proposed to drop specific mechanism for locator test and response

???

> 13. [What are privacy requirements for locator lists? Also  
> integrity - this
>      protocol is currently "in the clear".]

One person's privacy is the next person's debugging nightmare.

There is no privacy in today's multihoming either.

> 14. View forking as a unidirectional context state fork (based on a  
> ULP
>     signal) that assumes that the forked context state may then use a
>     different outgoing locator pair.

Forking is a bad idea, it increases the complexity of the shim  
manifold while pretty much the same functionality can also be  
provided in a different way.

> 16. SHIM6 control message sequence numbers are not needed here.  
> [control
>     messages]

My reachability/failure detection draft has sequence numbers of its  
own in the reachability probes.

> 18. Use a statically specified in the initial protocol  
> specification of
>     (10) seconds.

This means that senders must transmit something (data, keepalive)  
every 10 seconds, right? So the receiver needs to wait a bit LONGER  
than 10 seconds to time out.

Note that the tradeoff is:

< 240 seconds: we MUST repair the problem before TCP times out
 > 180 seconds: wait for BGP (90 - 180 second timeout) to fix the  
problem
< 90 & > 40 seconds: don't wait for BGP, but do wait for OSPF (40  
second timeout) to fix the problem
< 40 seconds: don't wait for OSPF

> 19. Continued exploration to see if a better locator pair is available
>     following identification of a viable locator is considered to  
> be an
>     experimental protocol extension. The exploration in the base  
> protocol
>     specification will terminate once a viable 9reachability  
> confirmed)
>     locator pair has been discovered.

In my draft I continue to search for "better" address pairs as  
defined by traffic engineering parameters. So if all locators have  
equal preference, there is no further exploration. If the current  
address pair is worse (= at least one of the two addresses has a  
lower preference than another potential source/dest address) the  
exploration continues for "better" pairs.

Delivery-date: Thu, 27 Oct 2005 11:59:34 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Comments on REAP draft
Date: Thu, 27 Oct 2005 13:58:58 +0200
To: Erik Nordmark <[email-masked]>

On 25-okt-2005, at 17:52, Erik Nordmark wrote:

>
> The protocol as described by the state machine doesn't seem to work  
> for ULPs
> that, even when they are "unhappy", space their retransmissions  
> more than
> 3 seconds apart.

[...]

> When I asked Jari about this before I think he said it was an  
> attempt to
> avoid a FBD keepalive message after the ULPs go silent (and are  
> happy).
> But I think this is fundamentally unavoidable. If the ULPs finish  
> exchanging
> packets, then I don't see how we can avoid having one end (the one  
> that last
> received a ULP packet) send a single FBD keepalive to the peer.

It is avoidable if after the final data packet, the other end sends  
an ACK and the protocol is smart enough to accept an ACK as an  
indiciation that communication works, but doesn't generate a  
keepalive after an ACK. In my draft, I assume that packets shorter  
than 20 bytes (excluding 20 bytes IPv6) are ACKs so FBD keepalives  
aren't generated for them.

This will of course lead to some extra work when a protocol only  
sends <= 20 byte packets in at least one direction, but I don't think  
that's too much of a problem.

> I don't understand the comment text that says:
>    The REAP design allows performing both failure detection and  
> address
>    pair exploration in the same sequence of messages, without a  
> need to
>    designate a specific point when the current address pair is  
> declared
>    inoperational and the search for a new pair begins.
> It seems like the timout event that triggers a message with Y=no is  
> quite
> different than the one that triggers a message with Y=yes. And the  
> one that
> causes a message with Y=no is the point at which the current  
> address pair
> has been declared inoperational. So I'm not convinced it is helpful to
> be able to have the "FBD keepalive" (the payload reception report) and
> the event reception report in the same shim6 message.

Especially as keepalives will be relatively frequent so it's helpful  
to keep them as small as possible.

Delivery-date: Thu, 27 Oct 2005 11:05:48 +0000
Date: Thu, 27 Oct 2005 14:05:42 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Comments on REAP draft

Erik Nordmark wrote:

>
> The protocol as described by the state machine doesn't seem to work 
> for ULPs
> that, even when they are "unhappy", space their retransmissions more than
> 3 seconds apart. This is because starting in "idle, when the ULP sends 
> one
> packet, we move to "suspected peer problem". But after 3 seconds 
> ("outgoing
> timeout") we move back to "idle".
> I don't think the protocol should make any assumptions on how frequently
> an unhappy ULP might retransmit.

Agreed. This was one of the known problems.

> When I asked Jari about this before I think he said it was an attempt to
> avoid a FBD keepalive message after the ULPs go silent (and are happy).
> But I think this is fundamentally unavoidable. If the ULPs finish 
> exchanging
> packets, then I don't see how we can avoid having one end (the one 
> that last
> received a ULP packet) send a single FBD keepalive to the peer.

Probably.

> I don't understand the comment text that says:
>    The REAP design allows performing both failure detection and address
>    pair exploration in the same sequence of messages, without a need to
>    designate a specific point when the current address pair is declared
>    inoperational and the search for a new pair begins.
> It seems like the timout event that triggers a message with Y=no is quite
> different than the one that triggers a message with Y=yes. And the one 
> that
> causes a message with Y=no is the point at which the current address pair
> has been declared inoperational. So I'm not convinced it is helpful to
> be able to have the "FBD keepalive" (the payload reception report) and
> the event reception report in the same shim6 message.

The Y bit causes indeed different behaviour. We can easily
define this as a separate message. For the moment I'm thinking
that there's more common in Y=0 & Y=1 than there's different.
For instance, it seems useful to carry same information about
what traffic/probes you have seen. It also seems useful (at least
in thinking some future load-balancing or true multipath
extensions) to be able to send multiple keepalives. Finally,
after short transient failures you may end up receiving the
peer's keepalive or a payload packet instead of one of the
explore acks. To me this says that behaviour-wise, we need
to be able to treat all this information.

But lets see what the full design is before we decide this.

> Is there an example of a case where both a payload reception report 
> and an
> event reception report is included in the same packet?

I think this is possible.

> I can't find one. Should this happen it would be an indication that
> payloads continue to be sent as alternate locators are used. In that 
> case the
> payload reception report might not contain enough information to tell 
> which
> locator pair was used; the locator pair might have switched due to the
> exploration. So *if* there is a case when payload reception reports 
> and event
> reception reports are used at the same time, then the payload reception
> report needs to include the locator pair(s) on which the payload(s) were
> received.

Yes. I don't remember whether I added this to the draft - I
guess not since you are asking. For NAT purposes it would
be also necessary to know where packets (including probes)
are received from.

> Looking at the packet diagram on page 16, I was also confused by the who
> actually detects the need to send a Y=no event.
> I think there are three cases to look at in more detail:
>     Locator pair stops working from A to B
>     Locator pair stops working from B to A
>     Locator pair stops working in both direction

My definition of sending a Y=no event was that if you
know you should get something from the other end (=
i.e. you are sending something yourself) and you are
not seeing anything, then you send this event. That is,
you make (1) a local decision of when there should be
traffic and (2) a local observation that you are not
receiving traffic.

> The state machine looks very complex (perhaps because I don't 
> understand it?).
> For instance, do we really need that many different timers?

I don't like this much complexity either. There are some things
that we can do easily. For instance, we can let "garbage collection"
handle giving up, which takes away one timer and some transitions.

For the rest, I think we need as much complexity as we have
to have. The flows that are in the draft are very simple, easy
to understand. But I think our protocol spec needs to handle
all cases. There's combinations of things that may make
this hard -- or maybe its just the representation. I don't know.

> The state names are hard for me to understand. For instance, it isn't 
> really

I'm open to suggestions...

> And one failure mode is when the current
> locator pair stops working in both directions, which doesn't seem to be
> captured in a separate state.

I'm not sure this is a mode that we should or even can show
in a spec that says how _one_ end of the communication behaves.
We don't know about this condition if we're not sending ourselves
anything. If we send ourselves something then it looks like the
peer's traffic is not getting to us; of course this could be due
to the whole connection being broken or our own packets getting
lost. (This is where I think the name of the state is misleading.)

And then, at the time the peer sends us a message informing
us that there's a problem, the mere reception of this message
implies that we no longer have a complete problem - at least
we are getting something from the peer. Of course, the current
pair may be completely inoperational. But again, the reception
of this message means that, as far as we are concerned, we have
already moved to another pair for the incoming direction - all
that's left is telling the peer that we saw his packet and he can
indeed use that pair.

> I think the protocol description can be simpler than state machine 
> description.
> I'll try to outline an event-based description in a separate email.

Ok. Looking forward to good suggestions!

--Jari

Delivery-date: Thu, 27 Oct 2005 10:38:50 +0000
Date: Thu, 27 Oct 2005 13:38:10 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: More REAP cases

Erik Nordmark wrote:

> This case is already in the draft, but it makes sense to add the timer 
> and
> more packets getting lost to show what happens:

Looks good, thanks!

> This shows when the failure for the current locator pair is in the other
> direction.
>
>     Peer A                                        Peer B
>       |                                             |
>       |           (A1,B1) payload packet            |
>       |-------------------------------------------->|
>       |                                             |
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------| Time T1
>       |                                             | Path B1->A1
>       |                                             | is now
>       |                                             | broken
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------|
>       |                                             |
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------|
>       |                                             |
>       |                                             | 10 seconds after 
> time
>       |                                             | T1, sends a com-
>       |       (B1,A1) REAP Event id=p,              | plaint that
>       |                          iseeyou=no         | it is not rec-
>       |   /-----------------------------------------| eiving anything
>       |                                             |
>       |       (B2,A2) REAP Event id=q,              |
>       |                          iseeyou=no         | Next try different
>       |<--------------------------------------------| locator pair
>       |                                             |

Add "this one gets through"

>       |   (A2, B2) REAP Event id=r,                 |
>       |                       iseeyou=yes           |
>       |                       payload reception rep |
>       |                       event reception rep(q)| This one gets
>       |-------------------------------------------->| through

s/This one gets through/now A responds/

>       |                                             |
>       |                                             |
>       |                                             | B now knows
>       |                                             | that A has no
>       |    (B2,A2) REAP Event id=s,                 | problem to receive
>       |                       iseeyou=yes,          | its packets and
>       |                       event reception rep(r)| This one gets
>       |<--------------------------------------------| that A has found
>       |                                             | a new path to B
>       |                                             |
>       |           (A2,B2) payload packet            |
>       |-------------------------------------------->| Payload packets
>       |                                             | flow again
>       |           (B2,A2) payload packet            |
>       |<--------------------------------------------|
>
Good case too, some nits above.

> This case we have even less luck. The response to the REAP event
> doesn't make it in the reverse direction, so both ends end up exploring
> indepedently.
>
>     Peer A                                        Peer B
>       |                                             |
>       |           (A1,B1) payload packet            |
>       |-------------------------------------------->|
>       |                                             |
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------| Time T1
>       |                                             | Path B1->A1
>       |                                             | is now
>       |                                             | broken
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------|
>       |                                             |
>       |           (B1,A1) payload packet            |
>       |   /-----------------------------------------|
>       |                                             |
>       |                                             | 10 seconds after 
> time
>       |                                             | T1, sends a com-
>       |       (B1,A1) REAP Event id=p,              | plaint that
>       |                          iseeyou=no         | it is not rec-
>       |   /-----------------------------------------| eiving anything
>       |                                             |
>       |       (B2,A2) REAP Event id=q,              |
>       |                          iseeyou=no         | Next try different
>       |<--------------------------------------------| locator pair
>       |                                             |
>   A know needs to
>   start exploring
>       |   (A2, B2) REAP Event id=r,                 |
>       |                       iseeyou=yes           |
>       |                       payload reception rep |
>       |                       event reception rep(q)|
>       |--------------------------------------/      | Doesn't make it
>       |                                             |
>       |   (A1, B1) REAP Event id=s,                 |
>       |                       iseeyou=yes           |
>       |                       payload reception rep |
>       |                       event reception rep(q)| This one gets
>       |-------------------------------------------->| through
>       |                                             |
>       |                                             |
>       |                                             | B now knows
>       |                                             | that A has no
>       |    (B2,A2) REAP Event id=t,                 | problem to receive
>       |                       iseeyou=yes,          | its packets and
>       |                       event reception rep(r)| This one gets
>       |<--------------------------------------------| that A has found
>       |                                             | a new path to B
>       |                                             |
>       |           (A1,B1) payload packet            |
>       |-------------------------------------------->| Payload packets
>       |                                             | flow again
>       |           (B2,A2) payload packet            |
>       |<--------------------------------------------|

Yes.

I have added these to the draft.

--Jari

Delivery-date: Wed, 26 Oct 2005 17:36:44 +0000
Date: Wed, 26 Oct 2005 10:36:04 -0700
From: David Meyer <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	John,

On Thu, Oct 27, 2005 at 02:08:50AM +1000, Geoff Huston wrote:
> >  From: John Payne <[email-masked]>
> > Subject: shim6 @ NANOG
> > Date: Wed, 26 Oct 2005 09:11:45 -0400
>=20
>=20
> Public thanks to Dave, Geoff, Vijay, Ted and Jason for their
> involvement in bringing shim6 to the NANOG conference.
>=20
> The messages I heard were:
>=20
> 1) Traffic engineering, traffic engineering and traffic engineering
>     - do NOT put this in the hands of the end system, this needs to
> be site level, or at the very least the site needs to be able to
> override the end system's decisions.
>=20
> 2) The first hit is of critical importance to content providers (many
> of whom couldn't legitimately justify a /32).  Hunting through DNS to
> find a locator that works won't fly.
>=20
> 3) It was good to hear in a widespread forum that shim6 is not
> expected to be THE only multihoming solution.  However, we were left
> uninformed as to where the other work is going on.

	Thanks. I'd also like to thank Geoff, Jason, Vijay, Ted,
	and everyone to participated in the BOF. I found the
	session to be quite productive, and I hope that it will
	form the foundation for an ongoing dialog. The IAB is
	hoping to do the next IAB "BOF" at APRICOT, so with any
	luck, see you all there. =20

	Thanks again all,

	Dave

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature
Content-Disposition: inline

--mYCpIKhGyMATD0i+--

Delivery-date: Wed, 26 Oct 2005 16:09:38 +0000
Date: Thu, 27 Oct 2005 02:08:50 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: shim6 @ NANOG   (forwarded note from John Payne)

 >  From: John Payne <[email-masked]>
 > Subject: shim6 @ NANOG
 > Date: Wed, 26 Oct 2005 09:11:45 -0400

Public thanks to Dave, Geoff, Vijay, Ted and Jason for their
involvement in bringing shim6 to the NANOG conference.

The messages I heard were:

1) Traffic engineering, traffic engineering and traffic engineering
     - do NOT put this in the hands of the end system, this needs to
be site level, or at the very least the site needs to be able to
override the end system's decisions.

2) The first hit is of critical importance to content providers (many
of whom couldn't legitimately justify a /32).  Hunting through DNS to
find a locator that works won't fly.

3) It was good to hear in a widespread forum that shim6 is not
expected to be THE only multihoming solution.  However, we were left
uninformed as to where the other work is going on.

Delivery-date: Tue, 25 Oct 2005 21:47:34 +0000
Date: Wed, 26 Oct 2005 07:45:31 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-hba-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           : Hash Based Addresses (HBA)
         Author(s)       : M. Bagnulo
         Filename        : draft-ietf-shim6-hba-01.txt
         Pages           : 22
         Date            : 2005-10-25

This memo describes a mechanism to provide a secure binding between
    the multiple addresses with different prefixes available to a host
    within a multihomed site.  The main idea is that information about
    the multiple prefixes is included within the addresses themselves.
    This is achieved by generating the interface identifiers of the
    addresses of a host as hashes of the available prefixes and a random
    number.  Then, the multiple addresses are generated by prepending the
    different prefixes to the generated interface identifiers.  The
    result is a set of addresses, called Hash Based Addresses (HBAs),
    that are inherently bound.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

Delivery-date: Tue, 25 Oct 2005 16:51:18 +0000
Date: Wed, 26 Oct 2005 02:50:57 +1000
To: Brian E Carpenter <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?
Cc: Erik Nordmark <[email-masked]>, [email-masked]

aha - thanks for clearing this up. I'm comfortable with "important work TBD"

   Geoff

At 03:53 PM 25/10/2005, Brian E Carpenter wrote:
>Geoff, I agree with you on that. I'm not asking for an easy answer,
>but more for a recognition in the base spec that this is important
>work TBD.
>
>     Brian
>
>Geoff Huston wrote:
>>I am not convinced about this - TE is a really complex issue here and I'm 
>>not sure that this initial base spec is capable of addressing the larger 
>>issues of TE in the SHIM6 context. There are a massive set of signalling 
>>issues that need to cover the differences between "sites" and "hosts" and 
>>"site TE policies" and "host locator preferences".
>>I'd rather not make arbitrary claims that are not covered in this base 
>>functionality spacification.
>>That does not say "lets ignore TE", but is _does_ say that TE is a tough 
>>problem and requires further consideration than will be found in this 
>>base specification.
>>
>>regards
>>    Geoff
>>   (co-chair hat removed)
>>
>>At 01:25 AM 25/10/2005, Erik Nordmark wrote:
>>
>>>Brian E Carpenter wrote:
>>>
>>>>6.1  Conceptual Data Structures
>>>>    The key conceptual data structure for the shim6 protocol is the host
>>>>    pair context.  This is a data structures which contains the following
>>>>    information:
>>>>    o  The peer ULID; ULID(peer)
>>>>    o  The local ULID; ULID(local)
>>>>    o  The list of peer locators, with their preferences; Ls(peer)
>>>>There's quite a lot in the draft about how preferences are communicated
>>>>and very little about where they come from. draft-ietf-shim6-arch-00.txt
>>>>doesn't help with this either. Somewhere, I think we need a list
>>>>of possible sources of these preferences, and dynamic or static TE policy
>>>>needs to be in that list.
>>>
>>>
>>>I see I didn't add this in the -02 document (which I submitted today) 
>>>but I agree that we should add some text to the next rev. of the proto 
>>>document.
>>>
>>>    Erik
>>>
>>>
>

Delivery-date: Tue, 25 Oct 2005 16:44:48 +0000
Date: Tue, 25 Oct 2005 09:43:52 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: More REAP cases

I tried to put together 2 more examples of REAP cases to handle.

    Erik

This case is already in the draft, but it makes sense to add the timer and
more packets getting lost to show what happens:

     Peer A                                        Peer B
       |                                             |
       |           (A1,B1) payload packet            |
       |-------------------------------------------->|
       |                                             |
       |           (B1,A1) payload packet            |
       |<--------------------------------------------| Time T1
       |                                             | Path A1->B1
       |           (A1,B1) payload packet            | is now
       |----------------------------------------/    | broken
       |                                             |
       |           (B1,A1) payload packet            |
       |<--------------------------------------------|
       |                                             |
       |           (A1,B1) payload packet            |
       |----------------------------------------/    |
       |                                             |
       |           (B1,A1) payload packet            |
       |<--------------------------------------------|
       |                                             |
       |           (A1,B1) payload packet            |
       |----------------------------------------/    |
       |                                             |
       |                                             | 10 seconds after 
time
       |                                             | T1, sends a com-
       |       (B1,A1) REAP Event id=p,              | plaint that
       |                          iseeyou=no         | it is not rec-
       |<--------------------------------------------| eiving anything
       |                                             |
    A realizes                                       |
    that it needs                                    |
    to start the                                     |
    exploration                                      |
       |                                             |
       |   (A1, B1) REAP Event id=q,                 |
       |                       iseeyou=yes           |
       |                       payload reception rep |
       |                       event reception rep(p)| But it gets lost
       |-------------------------------------/       | due to broken path
       |                                             |
    Retransmission                                   |
    to a different                                   |
    address                                          |
       |                                             |
       |   (A1, B2) REAP Event id=r,                 |
       |                       iseeyou=yes           |
       |                       payload reception rep |
       |                       event reception rep(p)| This one gets
       |-------------------------------------------->| through
       |                                             |
       |                                             |
       |                                             | B now knows
       |                                             | that A has no
       |    (B1,A1) REAP Event id=p,                 | problem to receive
       |                       iseeyou=yes,          | its packets and
       |                       event reception rep(r)| This one gets
       |<--------------------------------------------| that A has found
       |                                             | a new path to B
       |                                             |
       |           (A1,B2) payload packet            |
       |-------------------------------------------->| Payload packets
       |                                             | flow again
       |           (B1,A1) payload packet            |
       |<--------------------------------------------|

This shows when the failure for the current locator pair is in the other
direction.

     Peer A                                        Peer B
       |                                             |
       |           (A1,B1) payload packet            |
       |-------------------------------------------->|
       |                                             |
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------| Time T1
       |                                             | Path B1->A1
       |                                             | is now
       |                                             | broken
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------|
       |                                             |
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------|
       |                                             |
       |                                             | 10 seconds after 
time
       |                                             | T1, sends a com-
       |       (B1,A1) REAP Event id=p,              | plaint that
       |                          iseeyou=no         | it is not rec-
       |   /-----------------------------------------| eiving anything
       |                                             |
       |       (B2,A2) REAP Event id=q,              |
       |                          iseeyou=no         | Next try different
       |<--------------------------------------------| locator pair
       |                                             |
       |   (A2, B2) REAP Event id=r,                 |
       |                       iseeyou=yes           |
       |                       payload reception rep |
       |                       event reception rep(q)| This one gets
       |-------------------------------------------->| through
       |                                             |
       |                                             |
       |                                             | B now knows
       |                                             | that A has no
       |    (B2,A2) REAP Event id=s,                 | problem to receive
       |                       iseeyou=yes,          | its packets and
       |                       event reception rep(r)| This one gets
       |<--------------------------------------------| that A has found
       |                                             | a new path to B
       |                                             |
       |           (A2,B2) payload packet            |
       |-------------------------------------------->| Payload packets
       |                                             | flow again
       |           (B2,A2) payload packet            |
       |<--------------------------------------------|

This case we have even less luck. The response to the REAP event
doesn't make it in the reverse direction, so both ends end up exploring
indepedently.

     Peer A                                        Peer B
       |                                             |
       |           (A1,B1) payload packet            |
       |-------------------------------------------->|
       |                                             |
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------| Time T1
       |                                             | Path B1->A1
       |                                             | is now
       |                                             | broken
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------|
       |                                             |
       |           (B1,A1) payload packet            |
       |   /-----------------------------------------|
       |                                             |
       |                                             | 10 seconds after 
time
       |                                             | T1, sends a com-
       |       (B1,A1) REAP Event id=p,              | plaint that
       |                          iseeyou=no         | it is not rec-
       |   /-----------------------------------------| eiving anything
       |                                             |
       |       (B2,A2) REAP Event id=q,              |
       |                          iseeyou=no         | Next try different
       |<--------------------------------------------| locator pair
       |                                             |
   A know needs to
   start exploring
       |   (A2, B2) REAP Event id=r,                 |
       |                       iseeyou=yes           |
       |                       payload reception rep |
       |                       event reception rep(q)|
       |--------------------------------------/      | Doesn't make it
       |                                             |
       |   (A1, B1) REAP Event id=s,                 |
       |                       iseeyou=yes           |
       |                       payload reception rep |
       |                       event reception rep(q)| This one gets
       |-------------------------------------------->| through
       |                                             |
       |                                             |
       |                                             | B now knows
       |                                             | that A has no
       |    (B2,A2) REAP Event id=t,                 | problem to receive
       |                       iseeyou=yes,          | its packets and
       |                       event reception rep(r)| This one gets
       |<--------------------------------------------| that A has found
       |                                             | a new path to B
       |                                             |
       |           (A1,B1) payload packet            |
       |-------------------------------------------->| Payload packets
       |                                             | flow again
       |           (B2,A2) payload packet            |
       |<--------------------------------------------|

Delivery-date: Tue, 25 Oct 2005 16:40:38 +0000
Date: Tue, 25 Oct 2005 09:39:58 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Jari Arkko <[email-masked]>, [email-masked], Geoff Huston <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

marcelo bagnulo braun wrote:

> LLU message exchange is reliable i.e. there should be an ack back, right?
> so a node should not update the preferences of a locator set of which 
> the LLU message has not be acked imho

Sure, that is one possible way to resolve the synchronization issue.
(Putting them in the same Update message might perform a bit better though.)

But my point was really that we *have* a synchronization issue, even if 
we do not use some form of indicies as a compressed representation for 
the locators or locator pairs.

    Erik

Delivery-date: Tue, 25 Oct 2005 16:17:05 +0000
Cc: Jari Arkko <[email-masked]>, [email-masked], Geoff Huston <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Tue, 25 Oct 2005 18:17:06 +0200
To: Erik Nordmark <[email-masked]>

> And somewhere along the line I think we decided to do full updates and 
> not add/delete/change type updates.
> Thus a preference update would need to include all the locators (and 
> there preferences).
>
> I think this raises a synchronization issue even if we don't use 
> indicies. If A has sent {A1, A2} to B as a locator list option in the 
> past, and then sent {A1, A2, A3} as an update which hasn't been 
> acknowledged yet.
> When A then goes and want to update the preferences and sends {A1, A2, 
> A3} and their respective preferences, then what would happen if B 
> hasn't seen the LLU?

LLU message exchange is reliable i.e. there should be an ack back, 
right?
so a node should not update the preferences of a locator set of which 
the LLU message has not be acked imho

regards, marcelo

> Would it reject/ignore the preference update?
> It is exactly the same issue as when using indices I think.
> In the indicies case we represent the locator list using a small 
> generation number, and here we are sending the complete list of 
> locators, but the logic to resolve being out of synch still applies.
>
>    Erik
>
>

Delivery-date: Tue, 25 Oct 2005 16:07:31 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?
Date: Tue, 25 Oct 2005 18:07:31 +0200
To: Brian E Carpenter <[email-masked]>

Hi Brian,

I think this topic is interesting indeed and i share Geoff feeling=20
about complexity, but let me ask a bit more about this:

El 20/10/2005, a las 15:08, Brian E Carpenter escribi=F3:

> There's quite a lot in the draft about how preferences are =
communicated
> and very little about where they come from.=20
> draft-ietf-shim6-arch-00.txt
> doesn't help with this either. Somewhere, I think we need a list
> of possible sources of these preferences, and dynamic or static TE=20
> policy
> needs to be in that list.
>

what sources do you have in mind here?
- i can clearly see that local preferences like the local admin setting=20=

the local policy table to prefer some addresses over the others would=20
make sense. This would basically affect the selection of source=20
addresses and destiantions addresses used as ulids, as in the policy=20
table of rfc3484 and hence the locator used until a failure occurs. In=20=

addition, a similar mechanism could be available for following locators=20=

(after an outage)

- however, there seems to be other players that may want to also=20
influence in the preferences i.e. to be a source of preferences, in=20
particular, the peer. The peer can convey preferences about which=20
locators it want to use (this would only affect locators after a=20
rehoming event, since these preferences are conveyed once the session=20
is established so they are not good for selecting the initial=20
ulids/locators) (i can see some value on this, depending on the=20
scenario, as it has been discussed here)

Now, are you also considering here the isps as possible sources for=20
preference settings on a shim6 host? i mean, do you think that transit=20=

provider should have the possibility to inform the shim hosts about=20
what locators it prefers?

regards, marcelo

> Some discussion of traffic engineering in the architecture document
> would also seem necessary.
>
>     Brian
>
>

Delivery-date: Tue, 25 Oct 2005 15:54:14 +0000
Date: Tue, 25 Oct 2005 08:52:09 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Comments on REAP draft

The protocol as described by the state machine doesn't seem to work for ULPs
that, even when they are "unhappy", space their retransmissions more than
3 seconds apart. This is because starting in "idle, when the ULP sends one
packet, we move to "suspected peer problem". But after 3 seconds ("outgoing
timeout") we move back to "idle".
I don't think the protocol should make any assumptions on how frequently
an unhappy ULP might retransmit.

When I asked Jari about this before I think he said it was an attempt to
avoid a FBD keepalive message after the ULPs go silent (and are happy).
But I think this is fundamentally unavoidable. If the ULPs finish exchanging
packets, then I don't see how we can avoid having one end (the one that last
received a ULP packet) send a single FBD keepalive to the peer.

I don't understand the comment text that says:
    The REAP design allows performing both failure detection and address
    pair exploration in the same sequence of messages, without a need to
    designate a specific point when the current address pair is declared
    inoperational and the search for a new pair begins.
It seems like the timout event that triggers a message with Y=no is quite
different than the one that triggers a message with Y=yes. And the one that
causes a message with Y=no is the point at which the current address pair
has been declared inoperational. So I'm not convinced it is helpful to
be able to have the "FBD keepalive" (the payload reception report) and
the event reception report in the same shim6 message.

Is there an example of a case where both a payload reception report and an
event reception report is included in the same packet?
I can't find one. Should this happen it would be an indication that
payloads continue to be sent as alternate locators are used. In that 
case the
payload reception report might not contain enough information to tell which
locator pair was used; the locator pair might have switched due to the
exploration. So *if* there is a case when payload reception reports and 
event
reception reports are used at the same time, then the payload reception
report needs to include the locator pair(s) on which the payload(s) were
received.

Looking at the packet diagram on page 16, I was also confused by the who
actually detects the need to send a Y=no event.
I think there are three cases to look at in more detail:
	Locator pair stops working from A to B
	Locator pair stops working from B to A
	Locator pair stops working in both direction

The state machine looks very complex (perhaps because I don't understand 
it?).
For instance, do we really need that many different timers?
The state names are hard for me to understand. For instance, it isn't 
really
the peer that has a problem - the problem lies in the usage of a locator
pair in a particular direction. And one failure mode is when the current
locator pair stops working in both directions, which doesn't seem to be
captured in a separate state.

I think the protocol description can be simpler than state machine 
description.
I'll try to outline an event-based description in a separate email.

    Erik

Delivery-date: Tue, 25 Oct 2005 13:44:47 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-01.txt
Date: Tue, 25 Oct 2005 15:44:42 +0200
To: Erik Nordmark <[email-masked]>

El 20/10/2005, a las 15:30, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>
>>>> In section 5.4  R1 Message Format
>>>> It may make sense to allow the responder to include the locator set=20=

>>>> in the R1 message, so that the initiator can acknowledge the=20
>>>> reception of the locator set (otherwise, the locator set of the=20
>>>> responder is sent in R2 which remains unacknowledged).
>>>
>>>
>>> This isn't a problem AFAICT. If the initiator doesn't receive R2 it=20=

>>> will
>>> retransmit I2. The ULP packets from responder to initiator can still
>>> flow, since they haven't failed over to use an alternate locator =
pair
>>> yet.
>> right
>>>  Worst case would be a packet loss when we want to switch to
>>> alternate locators immediately as part of the context establishment
>>> (when the responder might start sending payload messages before the
>>> initiator has received the lost R2.)
>>>
>> yes, but this would also be covered by the context loss recovery=20
>> mechanism that is being considered, right? i mean, the peer could=20
>> reestablish the context with an alternative locators (and the same=20
>> ulids)
>
> Not clear actually.
>
> If the initiator hasn't received R2, it still has a context for its=20
> context tag (the one it sent in I1 and I2). The payload packets will=20=

> have that context tag.
> The initiator just doesn't have the peer context tag and the peer's=20
> locator list yet.
> So perhaps the reception of a data packet need to verify that the shim=20=

> context state in "ESTABLISHED" (reminds me that we need to write down=20=

> the state machine) in which case it would capture that it hasn't=20
> received the R2 yet.
>

not sure i am following you completely...
so, before the established state, the communication is not protected by=20=

the shim, so it wouldn't be possible to recover so far so good...

an initiator moves to established state once that it receives R2, right?
but when does the responder moves to established state?

>> actually this depends on what is being signed.
>> one possiblity is that the responder signs the locator list (without=20=

>> any context specific information). In this case, the responder=20
>> doesn't need to sign the locator list each time it sends a R1,=20
>> resulting in less processing.
>> the questions that are open here are reply attacks and if we need to=20=

>> sign also the locator list version...
>
> You would be subject to replay attacks of that signed list if you=20
> don't include something live in the signature (the context tag, a=20
> nonce, or something else)
>

yes, that may be an issue, perhaps we need to look this more in depth..

i was thinking that the signature would include the locator list=20
generation value, so that the right value must be placed there, but=20
that this is independent from the actual context i.e. a responder may=20
have a set of locator list generation values that it uses for the=20
initial locator lists that are exchanged during the host pair=20
establishment exchange. For these values it has a precomputed signature=20=

with its locator set, so that it doesn't need to resign the locator set=20=

each time...
this would provide some replay protection but limited, perhaps we need=20=

more. we can always include the context tag and solve the problem but=20
this would imply that a signature is required for each context (when=20
cgas are used of course)

but as i mention, i guess that the first thing would be to identify the=20=

potential replay attacks...
first of all, we are talking about replay attacks performed by an=20
attacker that once was on path, because if not, it does not has the=20
context tag i.e. no possibility to send any shim control packet at all.
In addition, we are considering the case of an attacker that obtains a=20=

previous LLU message containing a locator set signed by the cga and=20
that it includes this previous locator set and its signature in a=20
message with the new context tag.
Now, in any case, as far as we talked here, the locator set is accepted=20=

as potential source addresses just checking the context tag, right? (so=20=

no difference here made if including or not including the context tag=20
in the signature)
The next step would the include those locators as potential destination=20=

addresses. However, before doing that, the node that has received the=20
fake llu message will perform a reachability test to those addresses=20
(in order to prevent flooding)
If there is nobody there to answer, then the address won't be used.
If the host is reachable there, no problem neither.
I guess that the problematic case would be where the attacker manages=20
to receive the packets addressed to this locator that once was used by=20=

the shim node.... in fixed environments this may not be an issue, but=20
perhaps in mobile environments, this may be a problem (an attacker=20
following the track of a mobile user and using the addresses that it=20
leaves behind...) considering that cgas are likely to be used in a=20
mobile scenario, it may make sense to consider this... what do you=20
think?

the other threat here is to replay an old message containing all=20
stalled locators, resulting in a dos attack. In this case, verifying=20
the cga signature wouldn't help for protecting from this dos attack (i=20=

guess i make sense to take a decision considering both aspects... i=20
mean, if we decide to go for a verification of cga signature upon=20
reception to limit dos attacks caused by the introduction of all false=20=

locators in the locator set, we may also decide to include the context=20=

tag in the signature in order to prevent dos attacks caused by old llu=20=

messsages.)

So full protection with cgas could be achieved by including the context=20=

tag in the signature and verifying cga signature of received locator=20
set upon reception of the llu message. The cost for this is that we=20
need to: afford the cost of verifying locator sets that won't be=20
immediately used (and may will never be used). Include a context tag on=20=

the locator set signature, so each time a locator is established, we=20
need to sign the locator set.
>
>>> Or, we bite the bullet and have a larger context tag and ignore the
>>> source locator in the lookup.
>>>
>>> But in both cases we have an issue with injection of bad Update
>>> messages. What prevents the on-path attacker from injecting such a
>>> message and replacing the CGA parameter set with something, which=20
>>> when
>>> verified, will fail the verification?
>> nothing, but in this case we can detect that the message was false=20
>> and keep the last locator list that was verified
>
> If we want to allow lazy verification where a host doesn't verify a=20
> locator until it is about to use it to send to, then the whole list=20
> might never be verified.
> I don't know if this makes sense with HBA or CGA locators - presumably=20=

> for those the verification is just as cheap to do for the whole list=20=

> at once as doing it for one locator at a time.
>

Not really the case for hbas...
i mean for cgas, the full locator set list will be signed so verifying=20=

one is the same that verifying all of them
OTOH, hbas can be verified once at the time. I mean, for hbas, the=20
verification needed is that the locator to be used is contained in the=20=

same hba set than the ulid.
The hba verification procedure allows through a single hash operation=20
to verify this i.e. if two addresses belong to the same hba set.
n verifications would require n hashes i.e. generating the whole hba=20
set again

(in other words, there is an optimized mechanism defined that allows to=20=

verify if two addresses belong to the same hba set with a cost of one=20
hash operation i.e. that does not require regenerating the whole hba=20
set (with n hash operations)

regards, marcelo=

Delivery-date: Tue, 25 Oct 2005 13:37:41 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: the small stuff
Date: Tue, 25 Oct 2005 15:36:59 +0200
To: Erik Nordmark <[email-masked]>

On 13-okt-2005, at 7:49, Erik Nordmark wrote:

>> Forking

[...]

>> It might be useful to add a shim exchange that can support  
>> selecting  the right ULIDs in this case, though: that would be  
>> fairly light-weight.

> That would be an option.

> My understanding is that the request to be able to do forking  
> (which we've interpreted as different ULP traffic being able to use  
> different locator pairs to get to the same destination host),

My understanding is that it is having different locators for  
different contexts that use the SAME ULIDs...

> was requested by some transport folks.

> I don't know if we have a mechanism to ask them (whoever they were)  
> whether it is acceptable to do this using a ULID selection  
> mechanism, or whether the ULIDs should be the same but the locators  
> different.

It's hard to have a discussion with an unknown discussion partner.

I think we should certainly take their requirement for this  
functionality very serious, but not necessarily forking as the best  
way to achieve it. But it would be interesting to see feedback from  
transportation folk here, because the mess that this will result in  
is mostly in their back yard: they'll have to color different packets  
such that the application ToS requirements are communicated to the shim.

> In either case, the ULP needs to be updated to be capable to make  
> the shim setup forked context, so I assume there is some  
> flexibility on their end.

If we make this a function of the ULID selection then the  
applications can handle it with a new API without any/much  
involvement from the transports.

>> If we only need longer fields for a very small number of  
>> variables,  it's easier to redefine these variables so that they  
>> are broken in  255-byte chunks and put in two or more fields.

> This is an issue for the shim control messages. They need to be  
> able to carry
>  - lists of locators
>  - CGA parameter data structure
>  - CGA public key signature
> and I think we concluded that at least the last one might be larger  
> than 256 bytes. But I don't know how large the PDS might be.

I'm not sure how many locators you want, but those are only 16 bytes  
so you can have 15 in a max-255-byte option. Yes, crypto will be  
longer but if that's the only thing or pretty much the only thing it  
makes more sense to push the problem to the crypto option, like this  
for a 768 byte piece of crypto data:

type=crypto
len=255
seq=0
<data bytes 0 - 251>
type=crypto
len=255
seq=252
<data bytes 252 - 503>
type=crypto
len=255
seq=504
<data bytes 504 - 755>
type=crypto
len=12
seq=756
<data bytes 756 - 768>

But I guess I can live with 16 bit unaligned length fields...

As long as we avoid mixing alignments, i.e. stuff that is variable  
length in bytes and then something that is n-byte aligned: this needs  
variable length padding and becomes very messy.

> I'm not personally concerned with saving a few bytes in a control  
> message that might be a few hundred bytes.

Me neither, control messages are fair game.

>> Checksums
>> We didn't get a chance to discuss the issues surrounding the  
>> upper  layer checksum. As I've said before, I think we're best off  
>> rewriting  the TCP/UDP checksums along with the addresses. If we  
>> don't do this,  transport checksum calculation offloading will be  
>> a big problem in  IPv6. The potential for harmful actions from  
>> firewalls and such that  don't see a valid checksum is also  
>> significant. Howevever, this is  somewhat related to the  
>> suppressing of the shim header issue.

> And as I've said before, I think this is a very bad idea.
> In some cases, such as ESP, the shim might not be able to rewrite  
> the TCP checksum.

Yes, but as long as this situation is apparent at both ends (the fact  
that you can't see it's TCP because the next header field is  
encrypted is a good clue, but the presence of any AH or ESP header  
too, IMO) this shouldn't be problematic.

> So if we were to do this, then we'd end up with the semantics of  
> the checksum field being different depending on what extension  
> headers are in place.

Yes, that's true.

> I don't understand the statement which ends win "big problem in IPv6".
> Are you assuming that a lot of packets will be sent with a locator  
> pair that is different than the ULID pair?

Well, yes, if we define this as 0 < a lot < all. I don't think the  
actual number makes a difference.

> I think failures are and will be infrequent, so the fraction of  
> shim capable traffic which will be sent with a locator pair that is  
> different than the ULID pair will be vanishingly small.

So? If these packets are filtered out because of an apparently  
invalid checksum we don't have multihoming.

>> Demux on source with shim header

[...]

> I think that *if* we want to keep the door open to routers  
> rewriting the source address field, then we should seriously  
> consider 1) expanding the context tag to 47 bits and 2) look at the  
> security impact of not using the source address as part of the  
> lookup of the context on the receiver.

Yes, that makes sense. (Well, 40 - 44 bits would probably be enough  
too and leave a small number of bits for future use.)

> But I don't get the feeling that the WG has come to consensus on  
> whether we want to consider having routers rewriting the source  
> address.

That's probably because we really haven't solved the ingress  
filtering problem...

Delivery-date: Tue, 25 Oct 2005 13:14:04 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Tue, 25 Oct 2005 15:13:52 +0200
To: Erik Nordmark <[email-masked]>

On 13-okt-2005, at 4:48, Erik Nordmark wrote:

>> Right. I haven't thought much about the issues around locator   
>> updating because I was kind of assuming this wouldn't happen in  
>> the  presense of HBA.

> But it can with CGA.

Yes. I know this assumption was wrong.  :-)

>>> Any ideas on how to do this?

>> That would be something that we explore in the "how to safely   
>> suppress the shim header after rewriting" document but in the  
>> case  where the locator sets for the different ULIDs are disjoint  
>> this  isn't an issue: the receiver without state that receives a  
>> shimmed  packet without a shim header will know this because the  
>> packet is  addressed at a locator-only address. It can then either  
>> send back a  shim error or an ICMP error.

> Yes, but I thought we wanted the capability to do this in other  
> cases than the disjoint case (I've never been a fan of each host  
> that has N ULIDs needing to create (N*N - N) extra locators).

That's not a problem: if having n(n-1) locators is the only way that  
the shim header can safely be suppressed (I suspect there are other  
ways but maybe not) then there is a tradeoff between either having n 
(n-1) locators and no shim header after a rehoming (unless there are  
other complications such as extra headers), or having n locators and  
having a shim header in packets after a rehoming event.

> It seems to me that we can't make sure the we got the handling of  
> the "bit" correct until we know how the sender and receiver will  
> use this capability.

I'll be happy to write a draft...

Iljitsch

Delivery-date: Tue, 25 Oct 2005 13:08:46 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Second shim
Date: Tue, 25 Oct 2005 15:08:03 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-okt-2005, at 15:26, marcelo bagnulo braun wrote:

[...]

>> It would work as follows. The "second shim" intercepts session  
>> establishement requests (bind(), connect() and the like) along  
>> with the sending of UDP packets (sendto(), sendmsg()). The second  
>> shim then first tries the requested action using the addresses  
>> supplied by the application and/or RFC 3484 address selection  
>> mechanisms. When this action times out, the second shim looks up  
>> additional addresses (see below) and tries all source/dest  
>> combinations until something works. At that point the whole thing  
>> is handed back to the calling application and the second shim gets  
>> out of the way.

> First of all, i think it is important to exactly identify the  
> scenario that we are considering. I can see two scenarios here:
> - Scenario 1: the host that is initiating the communication  
> supports some multihoming specific mechanisms but the peer is just  
> a legacy IPv6 host (no special multihoming support)
> - Scenario 2: both hosts involved in the communication support  
> multihoming specific mechanisms (like the second shim that you are  
> talking about)

In order to provide decent multihoming capabilities we need to solve  
scenario 2, but a mechanism where we intercept the API calls  
mentioned above and retry them with different addresses until there  
is success works regardless of whether the correspondent supports the  
shim, so it also covers scenario 1.

> In scenario 1, the ULID and the locator used for the communication  
> need to be the same since the peer does not support the  
> translation, so, using a different ULID that the locator used would  
> break things.

Since this "second shim" sits between the application and the  
transport protocol, the breakage is very different from what happens  
below the transport: all transport-related functions work without  
trouble because the addresses the transport protocol sees are the  
ones on the wire. The only problem is that the application may think  
it's using a certain address while the communication is really using  
a different address.

> In this case, what we need would be the upgraded RFC3484 which  
> would allow to cycle through different source addresses.

RFC 3484 says _applications_ should cycle through all destination  
addresses. That's no good for two reasons:

1. as discussed in the interim meeting, cycling through just the  
destination addresses isn't enough to pass through ingress filtering  
and the like, you really need cycling through all possible address  
pairs (source as well as destination)

2. putting this burden on applications is bad because it means  
reinventing the wheel and if an application doesn't do the right  
thing multihoming won't work right (and cycling through all source/ 
dest pairs is hard to implement in applications)

[quote from RFC 3484]

> So this basically says that in very common scenarios, is actually  
> the IP layer that selects the source address. In this case, then it  
> would be possible to build additional mechanisms within the IP  
> layer that when a packet with unspecified source address is  
> received, it tries different source addresses and uses the one that  
> seems to be working

Yes, but we want this for the destination address too. But doing it  
for the source if left unspecified is better than nothing, I guess.

> (we still need to understand what does "seems to be working means  
> though..)

TCP and such: easy: the connection establishes. For UDP it's a bit  
harder but a packet coming back with the same source/dest addresses  
and port numbers but now reversed seems like a pretty good hint that  
things are working.

> This behavior would be transparent for ulp as long as they don't  
> specify the source address. If the source address is specified,  
> then the app should cycle through different source and destination  
> addresses. This seems to be coherent with the fact that the app is  
> specifying the source address

Yes. Applications generally specify a source address for a reason.

> In the second scenario, is what i understood that we called API on  
> steroids in the interim meeting, where the app asks to connect with  
> a given ulid and the shim will ask the resolver for the additional  
> addresses that the resolver obtained for that particular query, and  
> tries to connect using different locators, but keeping the same ULID.

That may be useful for some shim aware applications, but we need to  
be concerned with unmodified applications.

> This would cope with some failures but we need to keep in mind that  
> different addresses associated with a given FQDN may belong to  
> different hosts.

For these purposes, that's not important. Whether you connect to  
www1.cnn.com or www2.cnn.com (that both share the alias www.cnn.com)  
doesn't matter as they both provide the same service. Only once you  
have a session you don't want to jump to another host any longer.

Delivery-date: Tue, 25 Oct 2005 05:54:35 +0000
Date: Tue, 25 Oct 2005 07:53:45 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Geoff Huston <[email-masked]>
CC: Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?

Geoff, I agree with you on that. I'm not asking for an easy answer,
but more for a recognition in the base spec that this is important
work TBD.

     Brian

Geoff Huston wrote:
> 
> I am not convinced about this - TE is a really complex issue here and 
> I'm not sure that this initial base spec is capable of addressing the 
> larger issues of TE in the SHIM6 context. There are a massive set of 
> signalling issues that need to cover the differences between "sites" and 
> "hosts" and "site TE policies" and "host locator preferences".
> 
> I'd rather not make arbitrary claims that are not covered in this base 
> functionality spacification.
> 
> That does not say "lets ignore TE", but is _does_ say that TE is a tough 
> problem and requires further consideration than will be found in this 
> base specification.
> 
> 
> regards
> 
>    Geoff
>   (co-chair hat removed)
> 
> 
> At 01:25 AM 25/10/2005, Erik Nordmark wrote:
> 
>> Brian E Carpenter wrote:
>>
>>> 6.1  Conceptual Data Structures
>>>    The key conceptual data structure for the shim6 protocol is the host
>>>    pair context.  This is a data structures which contains the following
>>>    information:
>>>    o  The peer ULID; ULID(peer)
>>>    o  The local ULID; ULID(local)
>>>    o  The list of peer locators, with their preferences; Ls(peer)
>>> There's quite a lot in the draft about how preferences are communicated
>>> and very little about where they come from. draft-ietf-shim6-arch-00.txt
>>> doesn't help with this either. Somewhere, I think we need a list
>>> of possible sources of these preferences, and dynamic or static TE 
>>> policy
>>> needs to be in that list.
>>
>>
>> I see I didn't add this in the -02 document (which I submitted today) 
>> but I agree that we should add some text to the next rev. of the proto 
>> document.
>>
>>    Erik
>>
>>
>>
> 
> 

Delivery-date: Mon, 24 Oct 2005 22:38:35 +0000
Date: Tue, 25 Oct 2005 08:37:42 +1000
To: Erik Nordmark <[email-masked]>, Brian E Carpenter <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?
Cc: [email-masked]

I am not convinced about this - TE is a really complex issue here and I'm 
not sure that this initial base spec is capable of addressing the larger 
issues of TE in the SHIM6 context. There are a massive set of signalling 
issues that need to cover the differences between "sites" and "hosts" and 
"site TE policies" and "host locator preferences".

I'd rather not make arbitrary claims that are not covered in this base 
functionality spacification.

That does not say "lets ignore TE", but is _does_ say that TE is a tough 
problem and requires further consideration than will be found in this base 
specification.

regards

    Geoff
   (co-chair hat removed)

At 01:25 AM 25/10/2005, Erik Nordmark wrote:
>Brian E Carpenter wrote:
>
>>6.1  Conceptual Data Structures
>>    The key conceptual data structure for the shim6 protocol is the host
>>    pair context.  This is a data structures which contains the following
>>    information:
>>    o  The peer ULID; ULID(peer)
>>    o  The local ULID; ULID(local)
>>    o  The list of peer locators, with their preferences; Ls(peer)
>>There's quite a lot in the draft about how preferences are communicated
>>and very little about where they come from. draft-ietf-shim6-arch-00.txt
>>doesn't help with this either. Somewhere, I think we need a list
>>of possible sources of these preferences, and dynamic or static TE policy
>>needs to be in that list.
>
>I see I didn't add this in the -02 document (which I submitted today) but 
>I agree that we should add some text to the next rev. of the proto document.
>
>    Erik
>
>
>

Delivery-date: Mon, 24 Oct 2005 20:20:13 +0000
Date: Mon, 24 Oct 2005 23:20:00 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: new version of the reachability & exploration protocol

> Ah yes, but the diagram doesn't show that...

Ok, I fixed this for the next rev now.

>> Remember that this protocol
>> is designed to do both reachability and exploration at the
>> same time.
>
>
> I think it makes more sense to have different message types for this,  
> as the FBD keepalives will be relatively frequent but full  
> exploration hopefully much less frequent. Note though that I start a  
> full exploration after just missing one keepalive.

This isn't all that different from what I do... though we can
discuss the specific number or timing of what triggers exploration.

In my protocol 'I see you' == false means essentially that we
are still OK at least as far as the receiver's need for exploration
goes. So this is really just a keepalive for the receiver.

Conceptually, why I like a merged protocol is that it is
allows a smoother transition between reachability
and exploration. This can be important if you are still
hoping for a reachability test to succeed but already want
to proceed to trying out some other address pairs. Similarly,
this would seem to allow future extensions to load balancing,
exploration of alternative pairs while everything still works
etc.

> Well, the part that I wrote extensively about is very short in your  
> draft so it's hard for me to judge whether that part would be very  
> different.
>
> The most important difference that I see is that in my draft there is  
> per-context work and per-host work, while in your draft everything is  
> per-context.

I like your host/context difference approach.

We also need the other parts, including the nitty gritty details.
I'm hoping the two drafts together contain much of what is
needed.

> I'll be interested to see if my draft is accepted, as it doesn't have  
> any page breaks.

That's usually not a problem. The main problem they complain about
is the use of wrong legal copyright etc template.

--Jari

Delivery-date: Mon, 24 Oct 2005 19:00:38 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: new version of the reachability & exploration protocol
Date: Mon, 24 Oct 2005 20:59:53 +0200
To: Jari Arkko <[email-masked]>

On 24-okt-2005, at 18:51, Jari Arkko wrote:

>> In your fourth example the first communication from B to A is to   
>> complain that B doesn't receive any data. That's not really   
>> possible... If B has nothing else to send, and it doesn't receive   
>> anything, it will just assume the

> The example flow may need some explanation. At the point that the  
> first
> complaint is sent, B has been sending packets

Ah yes, but the diagram doesn't show that...

>> I'm not sure an explicity "I see you" flag is necessary, but maybe  
>> it  just functions as a "reply requested" flag...

> Well, I looked at your document today for five minutes, so I
> can't really say if it matches your reply requested flag.

It's not the same, but I think when all is said and done both flags  
pretty much accomplish the same thing, be it in different ways.

> However,
> in this protocol the "I see you" flag is used to initiate an
> exploration at the other side.

This isn't explicit in my draft. (I didn't have time to address less  
important details such as this one.)

> Remember that this protocol
> is designed to do both reachability and exploration at the
> same time.

I think it makes more sense to have different message types for this,  
as the FBD keepalives will be relatively frequent but full  
exploration hopefully much less frequent. Note though that I start a  
full exploration after just missing one keepalive.

>> I find the state diagram confusing: many of the states are non-  
>> obvious. I think it would be better to have a separate per- 
>> context  state diagram along with another state diagram for the  
>> reachability  testing. (Although in this draft you do not  
>> differentiate between per- context and host-wide behavior.)

> The draft did not yet take a stand on the exploration being per  
> host or
> per context. Did we reach a decision on this yet?

Would you seriously consider doing a reachability exploration for  
each shim context between two hosts when there is more than one shim  
context?

> Regarding the state diagram, you'll be even more confused when you
> find out some of the things it doesn't yet do.

:-)

> And its complex.

> Having said this, attempting to construct the diagram has been
> extremely educational. Its easy to throw a design on a slide
> or draft with example flows. But making the protocol operation
> waterproof in all scenarios is, ah, challenging.

Sure, a state diagram or two can be helpful, but I found the states  
that are in this one strange. Maybe these are the states that are  
required but I don't realize it yet, but it's also possible that  
organizing this differently makes everything clearer.

In general, it's a good idea to make two things that can do half the  
job independently rather than one big monolithic thing that does the  
whole job.

>> It's amusing to see that the protocols each of us came up with  
>> are  almost 100% different.

> :-) But lets see what the real differences are. I want to understand
> what your protocol does in order to determine whether the differences
> are in presentation or behaviour. From first look, I didn't actually
> see so many fundamental differences... the main difference appears
> to be formats, and that I wanted to handle both reachability and
> exploration with the same protocol.

Well, the part that I wrote extensively about is very short in your  
draft so it's hard for me to judge whether that part would be very  
different.

The most important difference that I see is that in my draft there is  
per-context work and per-host work, while in your draft everything is  
per-context.

>> BTW, my last name is "Van Beijnum" (capitalization of the V  
>> changes  depending on the presence of a first name or initials).

> Sorry. Hmm... not sure how to fix this in xml2rfc. I'll figure out
> it somehow.

I'll be interested to see if my draft is accepted, as it doesn't have  
any page breaks. It's annoying to make this silly layout by hand, but  
the xml stuff is worse.

Delivery-date: Mon, 24 Oct 2005 17:20:55 +0000
Date: Mon, 24 Oct 2005 19:51:46 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: new version of the reachability & exploration protocol

Iljitsch van Beijnum wrote:

> In your fourth example the first communication from B to A is to  
> complain that B doesn't receive any data. That's not really  
> possible... If B has nothing else to send, and it doesn't receive  
> anything, it will just assume the 

The example flow may need some explanation. At the point that the first
complaint is sent, B has been sending packets but is not hearing anything;
this is against the FBD rule so it kicks on a check/exploration.

> link is idle. But A is sending and  doesn't receive anything, so in 
> this case A will start the  reachability exploration at some point on 
> its own.

Yes. But that's not the case that this example tries to show; it tries to
show a situation where B->A gets through but A->B doesn't.

> I'm not sure an explicity "I see you" flag is necessary, but maybe it  
> just functions as a "reply requested" flag...

Well, I looked at your document today for five minutes, so I
can't really say if it matches your reply requested flag. However,
in this protocol the "I see you" flag is used to initiate an
exploration at the other side. Remember that this protocol
is designed to do both reachability and exploration at the
same time. So, for the regular FBD fillers in an unidirectional
case we simply set "I see you" = true, and the peer knows that
we are happing, simply letting him know that we see him
even if we have nothing to send ourselves.

If, on the other hand, we do not see any packets but we believe
we should be seeing them, then the flag is set to false. At that
point the peer knows that it needs to explore on its side to find
a working path to us.

When this finally is found, we see a packet and set the flag to
true in subsequent messages. Finally the peer sees this and
stops his exploration.

> I find the state diagram confusing: many of the states are non- 
> obvious. I think it would be better to have a separate per-context  
> state diagram along with another state diagram for the reachability  
> testing. (Although in this draft you do not differentiate between per- 
> context and host-wide behavior.)

The draft did not yet take a stand on the exploration being per host or
per context. Did we reach a decision on this yet?

Regarding the state diagram, you'll be even more confused when you
find out some of the things it doesn't yet do.

And its complex.

Having said this, attempting to construct the diagram has been
extremely educational. Its easy to throw a design on a slide
or draft with example flows. But making the protocol operation
waterproof in all scenarios is, ah, challenging.

So, I'm painfully aware that the diagram is hard to understand
and has even some real-life issues. However, whatever we do,
I'd really like to see us understand the small details, and the
behaviour of the protocol under different situations. If you
and I can't specify what the protocol is supposed to do in
different circumstances, will the implementers able to?

> It's amusing to see that the protocols each of us came up with are  
> almost 100% different.

:-) But lets see what the real differences are. I want to understand
what your protocol does in order to determine whether the differences
are in presentation or behaviour. From first look, I didn't actually
see so many fundamental differences... the main difference appears
to be formats, and that I wanted to handle both reachability and
exploration with the same protocol.

> BTW, my last name is "Van Beijnum" (capitalization of the V changes  
> depending on the presence of a first name or initials).

Sorry. Hmm... not sure how to fix this in xml2rfc. I'll figure out
it somehow.

--Jari

Delivery-date: Mon, 24 Oct 2005 16:08:53 +0000
Date: Mon, 24 Oct 2005 08:25:35 -0700
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: [email-masked]
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?

Brian E Carpenter wrote:

> 6.1  Conceptual Data Structures
> 
>    The key conceptual data structure for the shim6 protocol is the host
>    pair context.  This is a data structures which contains the following
>    information:
>    o  The peer ULID; ULID(peer)
>    o  The local ULID; ULID(local)
>    o  The list of peer locators, with their preferences; Ls(peer)
> 
> There's quite a lot in the draft about how preferences are communicated
> and very little about where they come from. draft-ietf-shim6-arch-00.txt
> doesn't help with this either. Somewhere, I think we need a list
> of possible sources of these preferences, and dynamic or static TE policy
> needs to be in that list.

I see I didn't add this in the -02 document (which I submitted today) 
but I agree that we should add some text to the next rev. of the proto 
document.

    Erik

Delivery-date: Mon, 24 Oct 2005 15:55:30 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: new version of the reachability & exploration protocol
Date: Mon, 24 Oct 2005 17:55:03 +0200
To: Jari Arkko <[email-masked]>

On 24-okt-2005, at 15:31, Jari Arkko wrote:

>   http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure- 
> detection-02.pdf
>   (A .txt version exists as well but does not contain the state  
> machine.)

> Comments and suggestions appreciated, as always.

In your fourth example the first communication from B to A is to  
complain that B doesn't receive any data. That's not really  
possible... If B has nothing else to send, and it doesn't receive  
anything, it will just assume the link is idle. But A is sending and  
doesn't receive anything, so in this case A will start the  
reachability exploration at some point on its own.

I'm not sure an explicity "I see you" flag is necessary, but maybe it  
just functions as a "reply requested" flag...

I find the state diagram confusing: many of the states are non- 
obvious. I think it would be better to have a separate per-context  
state diagram along with another state diagram for the reachability  
testing. (Although in this draft you do not differentiate between per- 
context and host-wide behavior.)

It's amusing to see that the protocols each of us came up with are  
almost 100% different.

BTW, my last name is "Van Beijnum" (capitalization of the V changes  
depending on the presence of a first name or initials).

Iljitsch

Delivery-date: Mon, 24 Oct 2005 13:31:06 +0000
Date: Mon, 24 Oct 2005 16:31:04 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: new version of the reachability & exploration protocol

A revision of this draft has been submitted and is for
the moment accessible at

http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-02.pdf
   (A .txt version exists as well but does not contain the state machine.)

This version of the draft contains a protocol for both
verifying reachability (FBD) and exploring for a working
pair, all part of an integrated solution that is quite
efficient in many respects. The protocol is intentionally
written in a standalone fashion to allow for potential
usage elsewhere (e.g. HIP).

There are some remaining issues that I did not find
solutions for before the deadline; these are pointed to
in the document at the relevant section.

Comments and suggestions appreciated, as always.

--Jari

Delivery-date: Mon, 24 Oct 2005 13:15:31 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: draft-ietf-shim6-reach-detect-01.txt
Date: Mon, 24 Oct 2005 15:14:28 +0200

Hi,

I hope the internet-drafts people are lenient, because I submitted it  
a few minutes late and with terrible formatting... For those who  
can't wait: http://www.muada.com/drafts/draft-ietf-shim6-reach- 
detect-01.txt

What I tried to do in this draft is to describe what really needs to  
happen to make reachability detection work. There is very little of  
the 00 version left, and there are also lots of details that weren't  
discussed in Amsterdam. An important new aspect is that reachability  
issues begin context-related, then go up/down to the global host-wide  
level and come back to the context level again at the end. I also did  
away with any host ids or context tags: implementations will simply  
have to infer this information from the locators used and/or trust  
that the other side knows what it's doing.

In the mean time, I gather that Jari absorbed the previous version of  
this draft into his. I haven't had time yet to look at his work, but  
at some point all of this has to merge so that will probably be  
interesting.

I'll be catching up with what has been happening on the list the past  
few weeks soon.

Iljitsch

Delivery-date: Sun, 23 Oct 2005 17:41:10 +0000
Date: Sun, 23 Oct 2005 19:40:48 +0200
From: Pierre Baume <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Subject: Re: Mention TE in draft-ietf-shim6-proto-01.txt?
Cc: [email-masked]

Hi Brian and all,

On 10/20/05, Brian E Carpenter <[email-masked]> wrote:
[...]

> There's quite a lot in the draft about how preferences are communicated
> and very little about where they come from. draft-ietf-shim6-arch-00.txt
> doesn't help with this either. Somewhere, I think we need a list
> of possible sources of these preferences, and dynamic or static TE policy
> needs to be in that list.
>
> Some discussion of traffic engineering in the architecture document
> would also seem necessary.
>
>      Brian

  Here's some text, below. It could be inserted in
draft-ietf-shim6-arch-00.txt after the 'Endpoint Identity' section.

Local Policy Settings

How does a host know which locator addresses can be used, in what
circumstances and how?

A Shim6-aware host needs a set of administrative and traffic
engineering policies:

- Locator addresses that can be used interchangeably, subject to
possible further constraints.

- Restrictions for the usage of some of the locator addresses, if
needed. They can be based on the ULP or on the availability of other
(preferred) located addresses.

- Recommandations for the proportions of traffic to send from
different locator addresses.

These parameters will be used in the Shim6 capability negociations
with other Shim6-aware protocol elements.

  I hope that this is going in the right direction. :-)

Pierre.

Delivery-date: Thu, 20 Oct 2005 13:51:47 +0000
Date: Thu, 20 Oct 2005 06:51:14 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Jari Arkko wrote:

> The latter case is indeed not simple! The 2nd para was
> saying that IF someone wants to take on such an ambitious
> task, then that dictates the solution.

I don't think it does.
If somebody wants to add that down the road, they can explicitly add the 
fact that the protocol needs to exchange the views of the addresses from 
the two ends (since they can be different due to NATs).

So I don't see why this consideration should be a constraint on the case 
protocol.

> If the ambition level is lower, then there are two truly
> alternative solutions, as noted in 1st para. Here the
> solution overall is simpler in any case. But there's still
> a difference, I think, compared between a solution
> that needs to be in sync vs. one that doesn't. Particularly
> if your set of addresses isn't fixed.

I don't think the complexity is very high to manage the generation number.
If the receiver gets an update message with a preference option where 
the generation number doesn't match the last one it received in a 
locator list option, then it knows that the sender hasn't received an 
ack for that new locator list. So it can just ignore the preference option.

The sender of the update retransmits each update (whether it contains a 
locator list, locator preferences, or both) until acknowledged.

The sender of the updates can benefit from some "collapsing" of the 
retransmissions but that is an optimization. By "collapsing" I mean that 
if the sender has an unacknowledged update (e.g., containing a locator 
list) and needs to send some other update (e.g., containing a preference 
option), then it can (re)transmit an update which contains both. This 
increases the probability that the peer will receive both at the same 
time, i.e. that the preferences will refer to the current locator list.

> Anyway, perhaps we should stop this philosophical debate
> and start talking about the specifics. Since we appear to
> agree that exploration doesn't use indexes, what does?

I haven't actually read your and Iljitsch' draft update to see how it 
handles different cases. I take it just uses the sequence numbers on the 
explore messages as the indication of what locator pairs was used (as 
you sketched in Amsterdam).

> LLU appears to not be able to use indexes, so is the
> question only about the update of preferences?

Yep.

And somewhere along the line I think we decided to do full updates and 
not add/delete/change type updates.
Thus a preference update would need to include all the locators (and 
there preferences).

I think this raises a synchronization issue even if we don't use 
indicies. If A has sent {A1, A2} to B as a locator list option in the 
past, and then sent {A1, A2, A3} as an update which hasn't been 
acknowledged yet.
When A then goes and want to update the preferences and sends {A1, A2, 
A3} and their respective preferences, then what would happen if B hasn't 
seen the LLU? Would it reject/ignore the preference update?
It is exactly the same issue as when using indices I think.
In the indicies case we represent the locator list using a small 
generation number, and here we are sending the complete list of 
locators, but the logic to resolve being out of synch still applies.

    Erik

Delivery-date: Thu, 20 Oct 2005 13:33:34 +0000
Date: Thu, 20 Oct 2005 16:33:42 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Geoff Huston <[email-masked]>,  [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Erik Nordmark wrote:

> Jari Arkko wrote:
>
>> I don't recall the exact discussion. FWIW, I think that both the
>> exploration and other parts of the protocol have a similar
>> situation with explicit  listing of addresses vs. using indexes:
>> the former creates a need to be very sure that we have
>> synchronized lists at both ends in the correct way. IPv6
>> addresses are large, so there's a tradeoff in packet size
>> vs. simplicity. At the moment my opinion is that we should
>> err on the side of simplicity.
>>
>> In addition, the exploration, reachability, initialization
>> and update parts have the added complication that if
>> we ever want to use these components of the protocol
>> for other purposes, then explicit addresses may be the
>> only way, given v4 NATs, v4-v6 translation mappings, etc.
>> may create different views about the addresses on the
>> two peers.
>
>
> I guess I somehow lost the simplicity in that second paragraph ;-)

:-)

The latter case is indeed not simple! The 2nd para was
saying that IF someone wants to take on such an ambitious
task, then that dictates the solution.

If the ambition level is lower, then there are two truly
alternative solutions, as noted in 1st para. Here the
solution overall is simpler in any case. But there's still
a difference, I think, compared between a solution
that needs to be in sync vs. one that doesn't. Particularly
if your set of addresses isn't fixed.

Anyway, perhaps we should stop this philosophical debate
and start talking about the specifics. Since we appear to
agree that exploration doesn't use indexes, what does?
LLU appears to not be able to use indexes, so is the
question only about the update of preferences?

--Jari

Delivery-date: Thu, 20 Oct 2005 13:31:08 +0000
Date: Thu, 20 Oct 2005 06:30:38 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-01.txt

marcelo bagnulo braun wrote:

>>> In section 5.4  R1 Message Format
>>> It may make sense to allow the responder to include the locator set 
>>> in the R1 message, so that the initiator can acknowledge the 
>>> reception of the locator set (otherwise, the locator set of the 
>>> responder is sent in R2 which remains unacknowledged).
>>
>>
>> This isn't a problem AFAICT. If the initiator doesn't receive R2 it will
>> retransmit I2. The ULP packets from responder to initiator can still
>> flow, since they haven't failed over to use an alternate locator pair
>> yet.
> 
> 
> right
> 
>>  Worst case would be a packet loss when we want to switch to
>> alternate locators immediately as part of the context establishment
>> (when the responder might start sending payload messages before the
>> initiator has received the lost R2.)
>>
> 
> yes, but this would also be covered by the context loss recovery 
> mechanism that is being considered, right? i mean, the peer could 
> reestablish the context with an alternative locators (and the same ulids)

Not clear actually.

If the initiator hasn't received R2, it still has a context for its 
context tag (the one it sent in I1 and I2). The payload packets will 
have that context tag.
The initiator just doesn't have the peer context tag and the peer's 
locator list yet.
So perhaps the reception of a data packet need to verify that the shim 
context state in "ESTABLISHED" (reminds me that we need to write down 
the state machine) in which case it would capture that it hasn't 
received the R2 yet.

> actually this depends on what is being signed.
> one possiblity is that the responder signs the locator list (without any 
> context specific information). In this case, the responder doesn't need 
> to sign the locator list each time it sends a R1, resulting in less 
> processing.
> the questions that are open here are reply attacks and if we need to 
> sign also the locator list version...

You would be subject to replay attacks of that signed list if you don't 
include something live in the signature (the context tag, a nonce, or 
something else)

> but this would imply that a host would need to keep track of all the 
> locators that once were available for the context, which would 
> potentially imply a much larger memory consumption than it would require 
> to just keep track of the current locator list

Yep.

>> Or, we bite the bullet and have a larger context tag and ignore the
>> source locator in the lookup.
>>
>> But in both cases we have an issue with injection of bad Update
>> messages. What prevents the on-path attacker from injecting such a
>> message and replacing the CGA parameter set with something, which when
>> verified, will fail the verification?
> 
> 
> nothing, but in this case we can detect that the message was false and 
> keep the last locator list that was verified

If we want to allow lazy verification where a host doesn't verify a 
locator until it is about to use it to send to, then the whole list 
might never be verified.
I don't know if this makes sense with HBA or CGA locators - presumably 
for those the verification is just as cheap to do for the whole list at 
once as doing it for one locator at a time.

> I think this problem is quite interesting indeed
> to summarize:
> Threats involved in accepting packet from unverified sources (this apply 
> both to using only the context tag to demux and to defer locator list 
> validation until we need to send packets to the locator)
> 
> 1- time shifted packet injection attack. This would allow an attacker 
> that were once on path and learned the context tag, to inject packets as 
> into a communication associated with a shim context. The difference with 
> current (non-shim) environment is that today the attacker needs to use a 
> topologically correct address to be able to spoof the source address and 
> inject packets into a communication. In the new context with the shim, 
> the attacker doesn't even need to by pass ingress filters since it can 
> simply send with its own source address and the shim will replace it 
> with the ULID used in the shim context.

Yes, if the attacker has seen the context tag it could do that.

> 2- Stalled locator list. (DoS attack) An attacker can update the locator 
> list with a new list of invalid locators, so that the victim won't be 
> able to accept any packets (if the source address is verified)
> 
> 
> others threats?
> 
> Possible solutions:
> - use only the context tag for demux: deal with issue #2 but not with 
> issue #1
> - keep a record of all previous locators: deal with issue #2 but not 
> with issue #1 (higher memory consumption)
> - verify the locator list using hba/cga: deals with both of them, but 
> imposes cpu consumption up front (even if we never need the alternative 
> locators)

Yes, the last one implies that even communication never fails we impose 
the overhead of verifying the locators in the list.

>    CGA Signature:
> 
>       A variable-length field containing a PKCS#1 v1.5 signature,
>       constructed by using the sender's private key over the following
>       sequence of octets:
> 
>       1. The 128-bit CGA Message Type tag [CGA] value for SHIM6, 0x4A
>          30 5662 4858 574B 3655 416F 506A 6D48.  (The tag value has been
>          generated randomly by the editor of this specification.).
> 
>       2. The Locator List Generation value of the correspondent Locator
>          List Option.
> 
>       3. The subset of locators included in the correspondent Locator
>          List Option which validation method is set to CGA. The locators
>          MUST be included in the order they are listed in the Locator
>          List Option.

Added.

>    This document defines a new 128-bit value under the CGA Message Type
>    [CGA] namespace, 0x4A30 5662 4858 574B 3655 416F 506A 6D48.

Added

> my thoughts were more simpler than that... :-)
> I was considering the case where the shim context is establsihed 
> upfront, before the communication is established. For instance, suppose 
> a host that knows that it usually establishes communications with other 
> peer and that it wants to establish a shim session up front for upcoming 
> communications... Not sure we want to do that, but i think that several 
> times we considered the possibility that the shim session is established 
> upfront (for instance when considering using shim for dealing with 
> initial contact failures)

I somehow lost track of what you wanted to change/add to the document 
for this.

    Erik

Delivery-date: Thu, 20 Oct 2005 13:08:32 +0000
Date: Thu, 20 Oct 2005 15:08:21 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Mention TE in draft-ietf-shim6-proto-01.txt?

I think we made an error in RFC 3582 by not mentioning transit
provider preferences explicitly in section 3.1.2, which only refers
to load sharing.

I suggest fixing that in the shim6 documents, and in the protocol
document I would suggest doing so principally in the first sentence
of the Introduction. Possible rewrite:

1.  Introduction

    The SHIM6 working group, and the MULTI6 WG that preceded it, is
    exploring a layer 3 shim approach for providing locator agility below
    the transport protocols, so that multihoming can be provided for IPv6
    with failover and load spreading properties [13] as well as transit
    provider preferences for traffic engineering, without assuming
    that a multihomed site will have a provider independent IPv6 address
    which is announced in the global IPv6 routing table.

I don't believe that any changes in basic shim6 are needed for this -
in fact I believe it's an RFC 3484 discussion to a large extent.

However, I have a related question about this:

6.1  Conceptual Data Structures

    The key conceptual data structure for the shim6 protocol is the host
    pair context.  This is a data structures which contains the following
    information:
    o  The peer ULID; ULID(peer)
    o  The local ULID; ULID(local)
    o  The list of peer locators, with their preferences; Ls(peer)

There's quite a lot in the draft about how preferences are communicated
and very little about where they come from. draft-ietf-shim6-arch-00.txt
doesn't help with this either. Somewhere, I think we need a list
of possible sources of these preferences, and dynamic or static TE policy
needs to be in that list.

Some discussion of traffic engineering in the architecture document
would also seem necessary.

     Brian

Delivery-date: Thu, 20 Oct 2005 13:07:11 +0000
Date: Thu, 20 Oct 2005 06:06:43 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Jari Arkko wrote:
> I don't recall the exact discussion. FWIW, I think that both the
> exploration and other parts of the protocol have a similar
> situation with explicit  listing of addresses vs. using indexes:
> the former creates a need to be very sure that we have
> synchronized lists at both ends in the correct way. IPv6
> addresses are large, so there's a tradeoff in packet size
> vs. simplicity. At the moment my opinion is that we should
> err on the side of simplicity.
> 
> In addition, the exploration, reachability, initialization
> and update parts have the added complication that if
> we ever want to use these components of the protocol
> for other purposes, then explicit addresses may be the
> only way, given v4 NATs, v4-v6 translation mappings, etc.
> may create different views about the addresses on the
> two peers.

I guess I somehow lost the simplicity in that second paragraph ;-)

    Erik

Delivery-date: Thu, 20 Oct 2005 12:37:54 +0000
Date: Thu, 20 Oct 2005 14:37:15 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Geoff Huston <[email-masked]>
CC: [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Register me as a "no objection" for all of those decisions.

    Brian

Delivery-date: Thu, 20 Oct 2005 07:01:38 +0000
Date: Thu, 20 Oct 2005 17:01:08 +1000
To: Jari Arkko <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Cc: Erik Nordmark <[email-masked]>, [email-masked]

thanks for the clarification Jari.

I believe that Jari's comment was the basis of the design
decision No. 8

   Geoff

At 04:40 PM 20/10/2005, Jari Arkko wrote:
>I don't recall the exact discussion. FWIW, I think that both the
>exploration and other parts of the protocol have a similar
>situation with explicit  listing of addresses vs. using indexes:
>the former creates a need to be very sure that we have
>synchronized lists at both ends in the correct way. IPv6
>addresses are large, so there's a tradeoff in packet size
>vs. simplicity. At the moment my opinion is that we should
>err on the side of simplicity.
>
>In addition, the exploration, reachability, initialization
>and update parts have the added complication that if
>we ever want to use these components of the protocol
>for other purposes, then explicit addresses may be the
>only way, given v4 NATs, v4-v6 translation mappings, etc.
>may create different views about the addresses on the
>two peers.
>
>--Jari
>
>Geoff Huston wrote:
>
>>Erik,
>>
>>My notes were more definite on that point, and I recall the discussion we 
>>had, and I thought we erred on the side of extreme caution / conservatism 
>>in terms of explicit enumeration of locator sets within control messages 
>>rather than assuming that the other end had a synchronized ordered set of 
>>locators that of course agreed with the local set.
>>
>>But if you are confident that this locator set synchronization is 
>>maintained within the control message exchange, then this design decision 
>>can be dropped and locators can be referred to by their index value 
>>within a synchronized ordering of the locator set.
>>
>>regards,
>>
>>Geoff
>>
>>
>>
>>At 02:54 PM 20/10/2005, Erik Nordmark wrote:
>>
>>>Geoff Huston wrote:
>>>
>>>>8.  Do not use locator ordering and index references in SHIM6 control
>>>>     messages in the initial base spec
>>>
>>>
>>>I'm not sure we really decided that at the Interim meeting. In the 
>>>current proto draft the locator preferences are expressed by assuming 
>>>that the locator list is ordered so that the relative position can be 
>>>used in the locator preferences without having to include all the 
>>>locators themselves in order to express the preferences.
>>>
>>>Jari did express that he didn't think this was necessary for the 
>>>reachability part, but I haven't checked how that work is evolving yet.
>>>
>>>So I think it is premature to make the above decision.
>>>
>>>    Erik
>>
>>
>>
>>
>>
>

Delivery-date: Thu, 20 Oct 2005 06:46:44 +0000
Date: Thu, 20 Oct 2005 16:46:29 +1000
To: "Spencer Dawkins" <[email-masked]>, <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

At 06:12 AM 20/10/2005, Spencer Dawkins wrote:
>>Hi,
>>
>>The following is a list of SHIM6 design decisions made at the interim
>>meeting of the SHIM6 WG, extracted from the meeting minutes. These
>>decisions are subject to confirmation by the WG. Your chairs invite you to
>>review these decisions and we'd like to understand the level of WG
>>consensus for these decisions by the end of next week (Friday 28th October).
>>
>>thanks,
>>
>>  Geoff & Kurtis
>>
>>2.  Use an 8 byte IP SHIM6 header in the base protocol specification for
>>    packets that require specific SHIM6 processing by the receiver, and
>>    allow optimizations on this, including that of a zero-length header, to
>>    be an experimental protocol extension.
>
>I'm not sure I understood the (several) protocol extensions we discussed 
>to be "experimental" - extensions to the base protocol, yes, but I didn't 
>remember the "experimental" part of the decision.

The discussion in the interim meeting was to approach the issue by making a 
number
of decisions that would allow a relatively straightforward specification of
shim6 as a 'base' protocol.

We would then look at a number of refinements in terms of richer signalling
sets, smaller IP packet headers, refined timer calculation as
"extensions" to the base shim6 protocol. We considered the use of
experimental RFCs as a means of publishing these extension documents
and then in the light of experience make a subsequent decision whether
to fold these extensions into a reissued protocol specification.

Hence the term "experimental protocol extension"

regards,

     Geoff

Delivery-date: Thu, 20 Oct 2005 06:40:09 +0000
Date: Thu, 20 Oct 2005 09:40:01 +0300
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

I don't recall the exact discussion. FWIW, I think that both the
exploration and other parts of the protocol have a similar
situation with explicit  listing of addresses vs. using indexes:
the former creates a need to be very sure that we have
synchronized lists at both ends in the correct way. IPv6
addresses are large, so there's a tradeoff in packet size
vs. simplicity. At the moment my opinion is that we should
err on the side of simplicity.

In addition, the exploration, reachability, initialization
and update parts have the added complication that if
we ever want to use these components of the protocol
for other purposes, then explicit addresses may be the
only way, given v4 NATs, v4-v6 translation mappings, etc.
may create different views about the addresses on the
two peers.

--Jari

Geoff Huston wrote:

> Erik,
>
> My notes were more definite on that point, and I recall the discussion 
> we had, and I thought we erred on the side of extreme caution / 
> conservatism in terms of explicit enumeration of locator sets within 
> control messages rather than assuming that the other end had a 
> synchronized ordered set of locators that of course agreed with the 
> local set.
>
> But if you are confident that this locator set synchronization is 
> maintained within the control message exchange, then this design 
> decision can be dropped and locators can be referred to by their index 
> value within a synchronized ordering of the locator set.
>
> regards,
>
> Geoff
>
>
>
> At 02:54 PM 20/10/2005, Erik Nordmark wrote:
>
>> Geoff Huston wrote:
>>
>>> 8.  Do not use locator ordering and index references in SHIM6 control
>>>     messages in the initial base spec
>>
>>
>> I'm not sure we really decided that at the Interim meeting. In the 
>> current proto draft the locator preferences are expressed by assuming 
>> that the locator list is ordered so that the relative position can be 
>> used in the locator preferences without having to include all the 
>> locators themselves in order to express the preferences.
>>
>> Jari did express that he didn't think this was necessary for the 
>> reachability part, but I haven't checked how that work is evolving yet.
>>
>> So I think it is premature to make the above decision.
>>
>>    Erik
>
>
>
>
>
>

Delivery-date: Thu, 20 Oct 2005 05:52:45 +0000
Date: Thu, 20 Oct 2005 15:52:22 +1000
To: Erik Nordmark <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Cc: [email-masked]

Erik,

My notes were more definite on that point, and I recall the discussion we 
had, and I thought we erred on the side of extreme caution / conservatism 
in terms of explicit enumeration of locator sets within control messages 
rather than assuming that the other end had a synchronized ordered set of 
locators that of course agreed with the local set.

But if you are confident that this locator set synchronization is 
maintained within the control message exchange, then this design decision 
can be dropped and locators can be referred to by their index value within 
a synchronized ordering of the locator set.

regards,

Geoff

At 02:54 PM 20/10/2005, Erik Nordmark wrote:
>Geoff Huston wrote:
>
>>8.  Do not use locator ordering and index references in SHIM6 control
>>     messages in the initial base spec
>
>I'm not sure we really decided that at the Interim meeting. In the current 
>proto draft the locator preferences are expressed by assuming that the 
>locator list is ordered so that the relative position can be used in the 
>locator preferences without having to include all the locators themselves 
>in order to express the preferences.
>
>Jari did express that he didn't think this was necessary for the 
>reachability part, but I haven't checked how that work is evolving yet.
>
>So I think it is premature to make the above decision.
>
>    Erik

Delivery-date: Thu, 20 Oct 2005 04:57:03 +0000
Date: Wed, 19 Oct 2005 21:54:08 -0700
From: Erik Nordmark <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: [email-masked]
Subject: Re: Design decisions made at the interim SHIM6 WG meeting

Geoff Huston wrote:

> 8.  Do not use locator ordering and index references in SHIM6 control
>     messages in the initial base spec

I'm not sure we really decided that at the Interim meeting. In the 
current proto draft the locator preferences are expressed by assuming 
that the locator list is ordered so that the relative position can be 
used in the locator preferences without having to include all the 
locators themselves in order to express the preferences.

Jari did express that he didn't think this was necessary for the 
reachability part, but I haven't checked how that work is evolving yet.

So I think it is premature to make the above decision.

    Erik

Delivery-date: Wed, 19 Oct 2005 20:13:06 +0000
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Wed, 19 Oct 2005 15:12:05 -0500

> Hi,
>
> The following is a list of SHIM6 design decisions made at the interim
> meeting of the SHIM6 WG, extracted from the meeting minutes. These
> decisions are subject to confirmation by the WG. Your chairs invite you to
> review these decisions and we'd like to understand the level of WG
> consensus for these decisions by the end of next week (Friday 28th 
> October).
>
> thanks,
>
>  Geoff & Kurtis
>
> 2.  Use an 8 byte IP SHIM6 header in the base protocol specification for
>    packets that require specific SHIM6 processing by the receiver, and
>    allow optimizations on this, including that of a zero-length header, to
>    be an experimental protocol extension.

I'm not sure I understood the (several) protocol extensions we discussed to 
be "experimental" - extensions to the base protocol, yes, but I didn't 
remember the "experimental" part of the decision.

Spencer 

Delivery-date: Wed, 19 Oct 2005 17:24:01 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-01.txt
Date: Wed, 19 Oct 2005 19:22:59 +0200
To: Erik Nordmark <[email-masked]>

El 18/10/2005, a las 22:22, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>> Hi,
>> i think that the document is improving rapidly, i send some comments=20=

>> below...
>
> Thanks for your comments.
>
> I've addressed the comments if they are not included in this response.
> Thus I'm just responding with clarifications and discussion points=20
> here.
>
>> In section 2.1  Definitions
>>    Host-pair context   The state that the multihoming shim maintains=20=

>> for
>>                        a particular peer.  The context is for a ULID
>>                        pair, as is identified by a context tag for=20
>> each
>>                        direction.
>> I would rather use the expression shim-context rather than host pair=20=

>> context, because since each context is associated to a given ULID=20
>> pair, there maybe more than one context for a given host pair, right?
>
> If we've nailed that down it might make sense to rename it ULID-pair
> context.

agree

> A "shim context" name doesn't indicate much about its scope.
>

right, that is why this would a good name even if we haven't nailed it=20=

down :-)

> But I'm not sure we've nailed that down completely; there might be =
some
> sharing of reachability state across different ULID-pairs for the same
> host-pair.
>

ok we can wait and see later

>> (moreover, as we consider the forking concept more in depth, there=20
>> maybe more than one context for a given ulid pair) so using the vague=20=

>> expression shim context would suit to whatever extent this evolves=20
>> to.
>
> But even with forking one context applies to only one ULID-pair.=20
> (Having
> multiple contexts per ULID pair doesn't change this.)
>

agree, the point was against host pair context terminology. I agree=20
that ulid pair context terminology is ok here too

>
>>    Even though we do not overload the flow label field to carry the
>>    context tag, any protocol (such as RSVP or NSIS) which signals
>>    information about flows from the host stack to devices in the =
path,
>>    need to be made aware of the locator agility introduced by a layer=20=

>> 3
>>    shim, so that the signaling can be performed for the locator pairs
>>    that are currently being used.
>> I would remove the first part of the sentence of this paragraph. I=20
>> mean, in the future when people read the spec, they won't be familiar=20=

>> with our flow label discussions, so this initial part of the sentence=20=

>> may sound a bit strange to them imho.
>
> Well, yes, but I'm more concerned about people understanding it now
> since we've changed direction a bit on this point. We can adjust this
> later (as in -03).
>

fine
>
>> and then the payload and control messages can be defined.
>> Then in section 5.2  Common Shim6 Control header
>>    The common part of the header has a next header and header=20
>> extension
>>    length field which is consistent with the other IPv6 extension
>>    headers, even if the next header value is always "NO NEXT HEADER"=20=

>> for
>>    the control messages
>> but before this header there can be other header, right? like the=20
>> routing header or hop-by-hop header.
>> My point is that this header is also located before
>>    any endpoint extension headers (fragmentation headers, destination
>>    options header, AH, ESP), but after any routing related headers=20
>> (hop-
>>    by-hop extensions header, routing header, a destinations options
>>    header which precedes a routing header).
>> The difference is that for now, no piggybacking of ulp in the shim=20
>> control messages is defined yet.
>
> And none planned! ;-)
> We know from MIPv6 endless discussions that piggybacking e.g. TCP
> payload on some other semantics carrying protocol is problematic, =
since
> since like packet policies (IPsec, firewalls) might want to let one=20
> part
> of the packet through and not another part of it.
>

ok, i wasn't aware that this was the problem

>> So i would state the location of the shim header and distinguish the=20=

>> case of payload messages where piggybacking of ulp is supported and=20=

>> control messages, where it is not.
>> This description would fit in the description of the common header=20
>> (since it is always placed in the same place)
>
> I don't understand what text you are suggesting to change, given that=20=

> we
> do not allow anything but nexthdr=3D59 for control messages.
>

no problem, i will wait to see how the result of the previous changes=20
so that probably this won't be an issue for me anymore

>> In section 5.4  R1 Message Format
>> It may make sense to allow the responder to include the locator set=20=

>> in the R1 message, so that the initiator can acknowledge the=20
>> reception of the locator set (otherwise, the locator set of the=20
>> responder is sent in R2 which remains unacknowledged).
>
> This isn't a problem AFAICT. If the initiator doesn't receive R2 it=20
> will
> retransmit I2. The ULP packets from responder to initiator can still
> flow, since they haven't failed over to use an alternate locator pair
> yet.

right

>  Worst case would be a packet loss when we want to switch to
> alternate locators immediately as part of the context establishment
> (when the responder might start sending payload messages before the
> initiator has received the lost R2.)
>

yes, but this would also be covered by the context loss recovery=20
mechanism that is being considered, right? i mean, the peer could=20
reestablish the context with an alternative locators (and the same=20
ulids)

> If we want to fix that, it might make more sense to make the receiver
> demux packets solely on the context tag, thus the source locator isn't
> used to lookup the context state. (This also allows router rewriting =
of
> source locators, which might be useful flexibility for the future.)
>
>
>> the potential problem with this is that an small I1 packet may result=20=

>> in a somehow big R1 packet which may be used by an attacker as an=20
>> amplifier (but i am not sure whether this is a big issue, since the=20=

>> amplification won't be so important)
>
> If you are going to send the locator list, wouldn't you need to also
> send that is needed by the peer to verify the list? For CGA that would
> imply generating a PK signature in order to send R1.
>

actually this depends on what is being signed.
one possiblity is that the responder signs the locator list (without=20
any context specific information). In this case, the responder doesn't=20=

need to sign the locator list each time it sends a R1, resulting in=20
less processing.
the questions that are open here are reply attacks and if we need to=20
sign also the locator list version...

...
> Either the host needs to track that it has an old (potentially still
> unverified) list of locators from the context establishment, and a new
> (unverified) list of locators from one (or more) update messages, and
> accept any one of those locators as a source.
>

but this would imply that a host would need to keep track of all the=20
locators that once were available for the context, which would=20
potentially imply a much larger memory consumption than it would=20
require to just keep track of the current locator list

> Or, we bite the bullet and have a larger context tag and ignore the
> source locator in the lookup.
>
> But in both cases we have an issue with injection of bad Update
> messages. What prevents the on-path attacker from injecting such a
> message and replacing the CGA parameter set with something, which when
> verified, will fail the verification?

nothing, but in this case we can detect that the message was false and=20=

keep the last locator list that was verified

I think this problem is quite interesting indeed
to summarize:
Threats involved in accepting packet from unverified sources (this=20
apply both to using only the context tag to demux and to defer locator=20=

list validation until we need to send packets to the locator)

1- time shifted packet injection attack. This would allow an attacker=20
that were once on path and learned the context tag, to inject packets=20
as into a communication associated with a shim context. The difference=20=

with current (non-shim) environment is that today the attacker needs to=20=

use a topologically correct address to be able to spoof the source=20
address and inject packets into a communication. In the new context=20
with the shim, the attacker doesn't even need to by pass ingress=20
filters since it can simply send with its own source address and the=20
shim will replace it with the ULID used in the shim context.

2- Stalled locator list. (DoS attack) An attacker can update the=20
locator list with a new list of invalid locators, so that the victim=20
won't be able to accept any packets (if the source address is verified)

others threats?

Possible solutions:
- use only the context tag for demux: deal with issue #2 but not with=20
issue #1
- keep a record of all previous locators: deal with issue #2 but not=20
with issue #1 (higher memory consumption)
- verify the locator list using hba/cga: deals with both of them, but=20
imposes cpu consumption up front (even if we never need the alternative=20=

locators)

>> In section 5.14.3  Locator Preferences Option Format
>> I am not sure i fully understand the format of this option...
>> For instance, all elements have the same length i.e. the Element=20
>> length field message applies to all the elements
>
> Yes.
>
> , or there is an Element Length
>> field for each Element item that follows? (i think it is the first=20
>> option, but the figure confuses me, because the Element[2] seems to=20=

>> have a different Length than Element[1] and Element[3]; other thing=20=

>> that confuses me about the figure is that the Element Length field=20
>> seems to have variable length or 2 octets (because it has two rows))
>
> The picture was messed up a bit, but all the Elements are two octets =
in
> it. Perhaps I need a different picture for each different Element Len?
>

Well, that would make it really clear but maybe it would be too much.
One option would be to depict one of the cases, for instance element=20
len =3D1 and put a note below the figure stating that this particular=20
case is depicted. At least i would suggest that the Element Len field=20
is depicted with 1 byte and separate the different element[i]

something like:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Type =3D 3          |0|            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Locator List Generation                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Element Len  |  Element[1]   |    Element[2] |   Element[3]  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    ~                              ...                              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            [The case of Element Len =3D 1 is depicted]

>> Besides, the signature defined in RFC3972 requires a 128-bit type tag=20=

>> for the message from the CGA Message Type name space that is specific=20=

>> to the usage of the CGA. In this case we would need to define such=20
>> for shim and declare it in the IANA considerations, so that IANA=20
>> assigns it. This 128 bit type tag is concatenated to what is being=20
>> signed, so i guess this needs to be included here.
>
> Does that mean we need to repeat the format from 3972?

well, no, i think that what is needed is to specify what is being=20
signed here...

> Send text.
>

i would suggest the following modification to the text (heavily=20
inspired from Send spec)

5.14.5  CGA Signature Option Format

    When CGA is used for validation of one or more of the locators in =
the
    Locator List Option, then the message in question will need to=20
contain
    this option.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Type =3D 5          |0|            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                         CGA Signature                         ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Fields:

    CGA Signature:

       A variable-length field containing a PKCS#1 v1.5 signature,
       constructed by using the sender's private key over the following
       sequence of octets:

       1. The 128-bit CGA Message Type tag [CGA] value for SHIM6, 0x4A
          30 5662 4858 574B 3655 416F 506A 6D48.  (The tag value has =
been
          generated randomly by the editor of this specification.).

       2. The Locator List Generation value of the correspondent Locator
          List Option.

       3. The subset of locators included in the correspondent Locator
          List Option which validation method is set to CGA. The =
locators
          MUST be included in the order they are listed in the Locator
          List Option.

In SEND they have decided to include in the option a hash of the public=20=

key used for signing, i guess this is for supporting multiple keys, but=20=

i am not sure we need this here...
I don't know if we want to include something else in the signature...

In addition, in the IANA considerations section the additional text=20
would be needed:

    This document defines a new 128-bit value under the CGA Message Type
    [CGA] namespace, 0x4A30 5662 4858 574B 3655 416F 506A 6D48.

>> Furthermore, i guess we need to specify what is being signed here. I=20=

>> guess it doesn't makes sense to sign the whole locator list, since=20
>> some of them are validated using HBAs. So a possible approach would=20=

>> be to extract from the locator list all of those that are validated=20=

>> through the CGA and sign those (ordered as they are included in the=20=

>> locator list),
>
> I was assuming that would be specified in the HBA draft.

but the HBA draft doesn't talk about signatures, since HBAs don't need=20=

them
Signatures are used when HBA features are not used and regular CGAs are=20=

used

>  But we can
> specify it in either draft I guess.
>
> How does Send/CGA prevent replays? Wouldn't that imply we need to sign
> more (the generation number?).

yes

> What is easiest to describe and perhaps implement is to sign the whole
> Update Message, but (except the signature option itself which we could
> require to be last). But that would be a bit odd in the sense that a
> locator preference option, when sent together with a locator list=20
> option
> using CGA, would be signed. But when the locator preference option is
> sent by itself it wouldn't be signed.
>

agree

> In any case, I don't see a problem with signing the whole Locator List
> option (plus whatever other pieces are needed) i.e. include any
> HBA-verified prefixes.
>

well this could be done either way: or signing only those locators=20
which verification method is CGA or the whole list.
the text above considers the first option, but i am fine either way for=20=

now

>
>> In section 7.5  Sending I1 messages
>>    If, after several retransmissions, there is no response, then most
>>    likely the peer does not implement the shim6 protocol, or there=20
>> could
>>    be a firewall that blocks the protocol.
>> I guess that this depends on whether there is an ongoing=20
>> communication or not. If there is an ongoing communication, then we=20=

>> can assume that the ulid is reachable, so if no answer is received=20
>> then is because of any of the two above reasons. However, if there is=20=

>> not an ongoing communication or if a failure has just occurred, maybe=20=

>> it is that the ULID selected in unreachable and other locators/ULIDs=20=

>> should be tried. Not sure what to do in this case...
>
> Failures before the context are up would need to be handled using
> "failures during initial contact" wouldn't they?
> Or is there a middle place where
>  - ULP has communicated a bit, but no context is created yet
>  - a failure occurs
> This would be complex to handle I think.
>

my thoughts were more simpler than that... :-)
I was considering the case where the shim context is establsihed=20
upfront, before the communication is established. For instance, suppose=20=

a host that knows that it usually establishes communications with other=20=

peer and that it wants to establish a shim session up front for=20
upcoming communications... Not sure we want to do that, but i think=20
that several times we considered the possibility that the shim session=20=

is established upfront (for instance when considering using shim for=20
dealing with initial contact failures)

>> In section 9.  Handling ICMP Error Messages
>>    But when the shim on the transmitting side
>>    replaces the ULIDs in the IP address fields with some other=20
>> locators,
>>    then an ICMP error coming back will have a "packet in error" which=20=

>> is
>>    not a packet that the ULP sent.  Thus the implementation will have=20=

>> to
>>    apply the reverse mapping to the "packet in error" before passing=20=

>> the
>>    ICMP error up to the ULP.
>> but the ICMP error won't have a shim payload header so, it won't be=20=

>> processed by the shim, right? or are we supposing that thee shim will=20=

>> inspect all packets (having the shim header or not) and identify ICMP=20=

>> error packets and in those inspect whther the inside packet contains=20=

>> a shim header and then do the processing?
>> I am especially concerned with the inspect all packets part, since i=20=

>> think i remeber talking in the meeting that this would result in=20
>> important performance issues...
>
> It's not all packets. An implementation which conforms to RFC 1122 =
need
> a mechanism to pass ICMP errors (as some form of error notifications)=20=

> to
> the ULPs on the host based on the next hdr values in the packet in=20
> error.
> Thus if the packet in error was TCP it passes an event to a TCP=20
> specific
> handler. And if the packet is SHIM6, it passes an event to a SHIM6
> specific handler. This handler can then figure out what to do next,
> based on the following next hdr value in the packet in error.

ok i didn't knew this

>
> Suggestions on how I can clarify this?
>

i would keep as it is, and we can assume that informed readers will=20
know what i didn't :-)

regards, marcelo

Delivery-date: Wed, 19 Oct 2005 04:12:08 +0000
Date: Wed, 19 Oct 2005 14:11:17 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Design decisions made at the interim SHIM6 WG meeting

Hi,

The following is a list of SHIM6 design decisions made at the interim
meeting of the SHIM6 WG, extracted from the meeting minutes. These
decisions are subject to confirmation by the WG. Your chairs invite you to
review these decisions and we'd like to understand the level of WG
consensus for these decisions by the end of next week (Friday 28th October).

thanks,

  Geoff & Kurtis

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

1.  The specification for initial contact will use RFC3484, as modified by
    this draft in terms of source address ordering.

2.  Use an 8 byte IP SHIM6 header in the base protocol specification for
    packets that require specific SHIM6 processing by the receiver, and
    allow optimizations on this, including that of a zero-length header, to
    be an experimental protocol extension.

3.  Use a header checksum on the SHIM6 control packets but not in the SHIM6
    packet header.

4.  Use a 32 bit context field with no checksum, and 15 reserved bits and a
    1 bit flag to indicate control / payload. Note potential DOS risks

5.  Possible experimental ULP API extensions to initial contact:

    5.1. Enhanced Contact would result in searching existing SHIM state
         based on initial locator set. (This may return a ULID pair that
         was not in the ULPs locator set is this a problem?)

    5.2. SHIM6 Contact would perform the contact step above, and where
         there was no SHIM6 context, then trigger SHIM6 state
         initialization and returned to the ULP the ULID pair with SHIM6
         state set up

    5.3. Ordered Locator Set (getaddr_pair_set_info()) returns an RFC3484
         ordering of locators based on local SHIM6 state information. This
         could be used to construct a connect_by_name() approach

6.  For SHIM6 control messages use a unidirectional acknowledged
    information transfer UPDATE and ACK message transaction as the base
    protocol, and then specify control messages in terms of control message
    types and attributes.

7.  Locator pairs are considered as unidirectional locator pairs, and there
    is no assumption that these must map into a bi-directional pair.

8.  Do not use locator ordering and index references in SHIM6 control
    messages in the initial base spec

9.  We need to indicate which LLU locators should be verified with HBA,
    CGA, or some future mechanism.

10. The SHIM6 packet formats have been updated to:
     * have a 32 bit context tag
     * checksum in same place as in the hip header
     * a 1/0 bit to distinguish the payload vs. control messages
     * have a 16 bit option type and length

    For the most control messages this results in 7+16 reserved bits. Most
    of the fields are 32 bit so they can't fit in here.

     * Adopt HIP parameter format for options; HIP parameter format
       defines length in bytes but guarantees 64-bit alignment.

11. Proposed to drop specific mechanism for locator test and response

12. Allow both locator set enumeration and HBA parameter set in an UPDATE
    message

13. [What are privacy requirements for locator lists? Also integrity - this
     protocol is currently "in the clear".]
    Place this topic into the larger item of possible areas of protocol
    extension, and note in the Security Considerations of the protocol
    specification that we have considered this and are advising that this
    falls into an area of potential protocol extension activity.

14. View forking as a unidirectional context state fork (based on a ULP
    signal) that assumes that the forked context state may then use a
    different outgoing locator pair.

15. On receipt of a SHIM6 payload packet where there is no current SHIM6
    context at the receiver, the receiver is to respond with an R1* packet
    in order to re-establish SHIM6 context. The R1* packet differs from the
    R1 packet in that an R1 packet echoes the I1 fields, while this R1*
    offers state back to the sender. Either way the next control packet is
    an I2 in response. The senders previous context state is to be flushed
    in receipt of the R2 packet following the R1*, I2 exchange

16. SHIM6 control message sequence numbers are not needed here. [control
    messages]

17. Use FBD as the reachability algorithm.

18. Use a statically specified in the initial protocol specification of
    (10) seconds.

19. Continued exploration to see if a better locator pair is available
    following identification of a viable locator is considered to be an
    experimental protocol extension. The exploration in the base protocol
    specification will terminate once a viable 9reachability confirmed)
    locator pair has been discovered.

Delivery-date: Tue, 18 Oct 2005 20:28:10 +0000
Date: Tue, 18 Oct 2005 13:22:05 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-01.txt

marcelo bagnulo braun wrote:
> Hi,
> 
> i think that the document is improving rapidly, i send some comments 
> below...

Thanks for your comments.

I've addressed the comments if they are not included in this response.
Thus I'm just responding with clarifications and discussion points here.

> In section 2.1  Definitions
> 
>    Host-pair context   The state that the multihoming shim maintains for
>                        a particular peer.  The context is for a ULID
>                        pair, as is identified by a context tag for each
>                        direction.
> 
> I would rather use the expression shim-context rather than host pair 
> context, because since each context is associated to a given ULID pair, 
> there maybe more than one context for a given host pair, right? 

If we've nailed that down it might make sense to rename it ULID-pair
context. A "shim context" name doesn't indicate much about its scope.

But I'm not sure we've nailed that down completely; there might be some
sharing of reachability state across different ULID-pairs for the same
host-pair.

> (moreover, as we consider the forking concept more in depth, there maybe 
> more than one context for a given ulid pair) so using the vague 
> expression shim context would suit to whatever extent this evolves to.

But even with forking one context applies to only one ULID-pair. (Having
multiple contexts per ULID pair doesn't change this.)

> Similarly, i wouldn't say that the Host-pair context is" The state that 
> the multihoming shim maintains for a particular peer." but rather  that 
> it is the "The state that the multihoming shim maintains for a 
> particular ULID pair." (at least for now)

I'll fix this.

>    Even though we do not overload the flow label field to carry the
>    context tag, any protocol (such as RSVP or NSIS) which signals
>    information about flows from the host stack to devices in the path,
>    need to be made aware of the locator agility introduced by a layer 3
>    shim, so that the signaling can be performed for the locator pairs
>    that are currently being used.
> 
> I would remove the first part of the sentence of this paragraph. I mean, 
> in the future when people read the spec, they won't be familiar with our 
> flow label discussions, so this initial part of the sentence may sound a 
> bit strange to them imho.

Well, yes, but I'm more concerned about people understanding it now
since we've changed direction a bit on this point. We can adjust this
later (as in -03).

> I guess that the common shim header would be the following:
> 
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |  Hdr Ext Len  |P|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> being P a flag that indicates whether this is a payload message (P set) 
> or this is a control message (P reset)

Good suggestion.

> and then the payload and control messages can be defined.
> 
> Then in section 5.2  Common Shim6 Control header
> 
>    The common part of the header has a next header and header extension
>    length field which is consistent with the other IPv6 extension
>    headers, even if the next header value is always "NO NEXT HEADER" for
>    the control messages
> 
> but before this header there can be other header, right? like the 
> routing header or hop-by-hop header.
> My point is that this header is also located before
>    any endpoint extension headers (fragmentation headers, destination
>    options header, AH, ESP), but after any routing related headers (hop-
>    by-hop extensions header, routing header, a destinations options
>    header which precedes a routing header).
> The difference is that for now, no piggybacking of ulp in the shim 
> control messages is defined yet.

And none planned! ;-)
We know from MIPv6 endless discussions that piggybacking e.g. TCP
payload on some other semantics carrying protocol is problematic, since
since like packet policies (IPsec, firewalls) might want to let one part
of the packet through and not another part of it.

> So i would state the location of the shim header and distinguish the 
> case of payload messages where piggybacking of ulp is supported and 
> control messages, where it is not.
> This description would fit in the description of the common header 
> (since it is always placed in the same place)

I don't understand what text you are suggesting to change, given that we
do not allow anything but nexthdr=59 for control messages.

> In section 5.4  R1 Message Format
> 
> It may make sense to allow the responder to include the locator set in 
> the R1 message, so that the initiator can acknowledge the reception of 
> the locator set (otherwise, the locator set of the responder is sent in 
> R2 which remains unacknowledged).

This isn't a problem AFAICT. If the initiator doesn't receive R2 it will
retransmit I2. The ULP packets from responder to initiator can still
flow, since they haven't failed over to use an alternate locator pair
yet. Worst case would be a packet loss when we want to switch to
alternate locators immediately as part of the context establishment
(when the responder might start sending payload messages before the
initiator has received the lost R2.)

If we want to fix that, it might make more sense to make the receiver
demux packets solely on the context tag, thus the source locator isn't
used to lookup the context state. (This also allows router rewriting of
source locators, which might be useful flexibility for the future.)

> the potential problem with this is that an small I1 packet may result in 
> a somehow big R1 packet which may be used by an attacker as an amplifier 
> (but i am not sure whether this is a big issue, since the amplification 
> won't be so important)

If you are going to send the locator list, wouldn't you need to also
send that is needed by the peer to verify the list? For CGA that would
imply generating a PK signature in order to send R1.

> In section 5.6  R2 Message Format
> 
>    CGA Parameter Data Structure: Included when the locator list is
>                   included and the PDS was not included in the context
>                   establishment messages, so the receiver can verify the
>                   locator list.
> This is kind of strange since this is one of the context establishment 
> messages...
> I guess it should read the same than in I2, i.e.
> 
>    CGA Parameter Data Structure: Included when the locator list is
>                   included so the receiver can verify the locator list.

Yes.Cut and paste error.

> In section 5.8  Update Request Message Format
> 
> As i understand the locator set contained in this message contains the 
> complete set of locators available, as opposed to including a 
> differential list of what are the new locators to be added/removed to 
> the locator list, right?

Correct.

> If this is so, i think this should be explicitly stated in this section.
> 
> In section 5.9  Update Acknowledgement Message Format
> 
>    This message is sent in response to a Update Request message.  It
>    implies that the Update Request has been received, and that any new
>    locators in the Update Request can now be used as the source locators
>    of packets.  But it does not imply that the (new) locators have been
>    verified
> 
> I am not sure what verifications are needed to accept a new locator as a 
> valid src address and which is needed for using it as a valid dst address.
> I mean, i clearly see that the reachability test used to prevent 
> flooding attacks is required before using the new locator as dest 
> address, but it is not needed before accepting packets with this locator 
> as src address. But, are the HBA/CGA verifications required before 
> accepting  packets with the new locator as src address? In other words, 
> does the receiver of a update request message needs to perform HBA/CGA 
> validation before sending the update ack packet?

I don't think so. That would imply that the same requirement would apply
to the context establishment. It makes sense to be able defer the
HBA/CGA verification as well as the return routability check until the
locator is about to be used as a destination. That way we can get the RR
check for free as part of the reachability testing that will happen in
any case.

> Let's see this a bit more in detail... accepting packets from unverified 
> locators in src address would allow an attacker to inject packets in a 
> communication associated with a shim context, even though the peer will 
> be still sending packets to the verified address. Of course for doing 
> that, the attacker needs to determine the context tag, so it needs to 
> have been on path once (and also need to use a sequence number in the 
> locator update higher than the one currently used), so it doesn't seems 
> so easy. However, accepting an unverified locator set may cause 
> problems, in particular suppose that the attacker sends a packet with a 
> very high seq number and the correct context tag, but it includes a 
> locator list that contains all invalid locators. The victim accepts the 
> list and substitutes the old (valid) list by the new (false) list. The 
> result is a DoS attack, since there won't be any locator valid in the 
> new list. Basically, accepting unverified lists of locators would enable 
> time-shifted DoS attacks. This can be prevented by performing hba/cga 
> verification before accepting the locator list. This has a cost though, 
> since we need to make all the computation effort of verifying the 
> locator list upon the reception of the list, even if we may not need the 
> alternative locators ever.

Either the host needs to track that it has an old (potentially still
unverified) list of locators from the context establishment, and a new
(unverified) list of locators from one (or more) update messages, and
accept any one of those locators as a source.

Or, we bite the bullet and have a larger context tag and ignore the
source locator in the lookup.

But in both cases we have an issue with injection of bad Update
messages. What prevents the on-path attacker from injecting such a
message and replacing the CGA parameter set with something, which when
verified, will fail the verification?

> In section 5.10  Reachability Probe Message Format
> 
>    This message includes the ULID pair as well as the context tag, so
>    that the peer can indeed verify that it has that ULID and that the
>    context tag is correct.
> 
> Just to keep in mind Iljitsch suggestion to be able to use a single 
> reachability probe when multiple contexts were using the same locator 
> pair, so that no multiple probes to the same locator pair are needed. 
> For this, we need something different than simply the context tag and 
> the ulid pair. Perhaps all the ulids and context tags of the involved 
> context would be enough rather then move to new namespaces as hostids...

Yes. I haven't yet read Jari's and Iljitsch draft to see what will happen
here. Perhaps we'll end up removing the definition of the reachability
related packet formats from the proto document and have them in the
reachability document.

> In section 5.14  Option Formats
> 
> it is stated that:
> 
>    Total Length = 11 + Length - (Length + 3) % 8;
> 
> wouldn't that be
> 
>    Total Length = 12 + Length - (Length + 4) % 8;

I just stole that from the HIP spec, so how would I know ;-)

When Length = 4, no padding is needed so the Total should be 8.
But your formula ends with with 16 in that case.
When Length = 5 we need 7 bytes of padding for a total of 16, which we
get from both formulas.
When Length=12 no padding is needed so Total should be 16. Etc.

> In section 5.14.1  Validator Option Format
> 
> wouldn't it make sense to define different option types for different 
> hash functions used for the validator? like 1 for sha1 validator, 2 for 
> md5 and so on, so that different hash functions are supported? (and it 
> is possible to move from one to another hash function by supporting many 
> of them?

The responder can use whatever way it wants, including the phase of the
moon, as the validator. The initiator doesn't do anything with it other
than return it in I2.

> In section 5.14.3  Locator Preferences Option Format
> 
> I am not sure i fully understand the format of this option...
> 
> For instance, all elements have the same length i.e. the Element length 
> field message applies to all the elements

Yes.

, or there is an Element Length
> field for each Element item that follows? (i think it is the first 
> option, but the figure confuses me, because the Element[2] seems to have 
> a different Length than Element[1] and Element[3]; other thing that 
> confuses me about the figure is that the Element Length field seems to 
> have variable length or 2 octets (because it has two rows))

The picture was messed up a bit, but all the Elements are two octets in
it. Perhaps I need a different picture for each different Element Len?

> Besides, the 
> signature defined in RFC3972 requires a 128-bit type tag for the message 
> from the CGA Message Type name space that is specific to the usage of 
> the CGA. In this case we would need to define such for shim and declare 
> it in the IANA considerations, so that IANA assigns it. This 128 bit 
> type tag is concatenated to what is being signed, so i guess this needs 
> to be included here.

Does that mean we need to repeat the format from 3972?
Send text.

> Furthermore, i guess we need to specify what is being signed here. I 
> guess it doesn't makes sense to sign the whole locator list, since some 
> of them are validated using HBAs. So a possible approach would be to 
> extract from the locator list all of those that are validated through 
> the CGA and sign those (ordered as they are included in the locator list),

I was assuming that would be specified in the HBA draft. But we can
specify it in either draft I guess.

How does Send/CGA prevent replays? Wouldn't that imply we need to sign
more (the generation number?).
What is easiest to describe and perhaps implement is to sign the whole
Update Message, but (except the signature option itself which we could
require to be last). But that would be a bit odd in the sense that a
locator preference option, when sent together with a locator list option
using CGA, would be signed. But when the locator preference option is
sent by itself it wouldn't be signed.

In any case, I don't see a problem with signing the whole Locator List
option (plus whatever other pieces are needed) i.e. include any
HBA-verified prefixes.

> In section 7.5  Sending I1 messages
> 
>    If, after several retransmissions, there is no response, then most
>    likely the peer does not implement the shim6 protocol, or there could
>    be a firewall that blocks the protocol.
> 
> I guess that this depends on whether there is an ongoing communication 
> or not. If there is an ongoing communication, then we can assume that 
> the ulid is reachable, so if no answer is received then is because of 
> any of the two above reasons. However, if there is not an ongoing 
> communication or if a failure has just occurred, maybe it is that the 
> ULID selected in unreachable and other locators/ULIDs should be tried. 
> Not sure what to do in this case...

Failures before the context are up would need to be handled using
"failures during initial contact" wouldn't they?
Or is there a middle place where
  - ULP has communicated a bit, but no context is created yet
  - a failure occurs
This would be complex to handle I think.

> In section 9.  Handling ICMP Error Messages
> 
>    But when the shim on the transmitting side
>    replaces the ULIDs in the IP address fields with some other locators,
>    then an ICMP error coming back will have a "packet in error" which is
>    not a packet that the ULP sent.  Thus the implementation will have to
>    apply the reverse mapping to the "packet in error" before passing the
>    ICMP error up to the ULP.
> 
> but the ICMP error won't have a shim payload header so, it won't be 
> processed by the shim, right? or are we supposing that thee shim will 
> inspect all packets (having the shim header or not) and identify ICMP 
> error packets and in those inspect whther the inside packet contains a 
> shim header and then do the processing?
> I am especially concerned with the inspect all packets part, since i 
> think i remeber talking in the meeting that this would result in 
> important performance issues...

It's not all packets. An implementation which conforms to RFC 1122 need
a mechanism to pass ICMP errors (as some form of error notifications) to
the ULPs on the host based on the next hdr values in the packet in error.
Thus if the packet in error was TCP it passes an event to a TCP specific
handler. And if the packet is SHIM6, it passes an event to a SHIM6
specific handler. This handler can then figure out what to do next,
based on the following next hdr value in the packet in error.

Suggestions on how I can clarify this?

> 10.  Teardown of the Host Pair Context
> 
>    Each host can unilaterally decide when to tear down a host-pair
>    context.  It is RECOMMENDED that hosts not tear down the context when
>    they know that there is some upper layer protocol that might use the
>    context.
> 
> Not sure i agree here. I recall Iljitsch suggestion that servers could 
> tear down context prematurelly and leave up to the clients the recovery 
> effort, using the context loss recovery mechanisms in order to reduce 
> the load imposed by the shim. This sounds like a very nice approach to 
> me. so i am not sure i agree with the reccomend here (perhaps i fail to 
> see what the reccomend term implies...

Added as an open issue.

> Section 16.  Open Issues
> 
>    The following open issues are known:
>    o  Is there need for keeping the list of locators private between the
>       two communicating endpoints?  We can potentially accomplish that
>       when using CGA but not with HBA, but it comes at the cost of doing
>       some public key encryption and decryption operations as part of
>       the context establishment.
> 
> I think that the option selected for this is a future extension of the 
> protocol

Yep

>    o  Forking the context state.  On the mailing list we've discussed
>       the need to fork the context state, so that different ULP streams
>       can be sent using different locator pairs.  No protocol extensions
>       are needed if any forking is done independently by each endpoint.
>       But if we want A to be able to tell B that certain traffic (a
>       5-tuple?) should be forked, then we need a way to convey this in
>       the shim6 protocol.  The hard part would be defining what
>       selectors can be specified for the filter which determines which
>       traffic uses which of the forks.  So the question is whether we
>       really need signaling for forking, or whether it is sufficient to
>       allow each endpoint to do its own selection of which locator pair
>       it is using for which traffic.
> 
> imho for this what is needed is the capability of setting multiple 
> context with the same ULID pair but with different context tags, and an 
> API that allows the ulp to signal the shim which context is to be used 
> (what the doc calls primary vs other contexts i think)

Yes.

    Erik

Delivery-date: Tue, 18 Oct 2005 20:06:11 +0000
Date: Tue, 18 Oct 2005 05:12:43 -0700
From: Erik Nordmark <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-01.txt

Shinta Sugimoto wrote:

> Yes. Thank you for the clarification.  But I still have unclear point.
> My question is, in short, how the shim6 can be switched on/off
> by ULP.  Such idea might be silly but let me try to explain that:
> 
> Suppose that a node A has address {A1,A2 and A3} and A1 is anyhow
> selected as ULID.  In such case, app1 may want take advantage of shim6
> and specify A1 as the source address for its flow.  OTOH, app2 may not
> be requesting shim6 support at all.  How would the system allow app2 not
> to use shim6 ?  Maybe app2 may avoid its flow to be shimmed by
> specifying A2 or A3 as the source address.  But how come app2 know that
> A1 is served as shim6 as ULID ?  Or is there any other mechanism which
> allows ULP to switch on/off shim6 ?

To do this we just need to define a new API, for instance an 
IPV6_DONTSHIM socket option.

> You are right. The problem was not that simple...
> In HBA, secure binding between the set of prefixes and the HBAs
> is assured.  With CGA, a node can verify if the received packet
> was actually sent by the right peer.  With HBA/CGA, we can have
> both.  But the issue we are discussing here is how one can verify
> if the ULID is owned by the node which actually resides on the
> location (from network topology perspective) indicated by the ULID.

Need to do a return routability check i.e. send a packet and get a 
response in order to verify that the ULID is indeed present at that locator.

>>Instead the shim uses a "probe" to verify that the ULID is 
>>indeed present at the locator before sending packets to it.
> 
> 
> I believe you are referring to Reachability Probe message
> in shim6 ?  As far as I understand it, the message is for checking
> if the peer can be reachable with claimed locator.  Hence seems to
> me it's for solving a different issue.

It has two purposes.

> I see it's difficult to handle a situation like above.  During the
> renumbering process, the old IP addresses should be deprecated,
> including ULID, IMHO.  So probably shim6 should follow the direction
> of the lower layer in determining continuation of given ULID.  I
> didn't find any description about the ULID availability in protocol
> document.  For instance what would be expected behavior of shim6
> when ULID is become unavailable (i.e. preferred lifetime of the IPv6
> address (=ULID) has been expired) ?

This is an open issue. I'll add it to -02.

    Erik

Delivery-date: Tue, 18 Oct 2005 09:01:45 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Fwd: I-D ACTION:draft-bagnulo-shim6-cga-ext-00.txt 
Date: Tue, 18 Oct 2005 11:01:15 +0200

We have submitted this draft that defines a generic TLV format for cga 
extensions.
We think this is important to have, in order to allow multiple 
extensions supported in CGAs, HBAs being one of them.
Since HBA is the first one, we need to address this too, otherwise, 
after the HBAs are done, we may need to modify them in order to be 
compliant with the generic format.

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 17 de octubre de 2005 21:50:02 GMT+02:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-bagnulo-shim6-cga-ext-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Cryptographically Generated Addresses (CGA) Extension Field 
> Format
> 	Author(s)	: M. Bagnulo, J. Arkko
> 	Filename	: draft-bagnulo-shim6-cga-ext-00.txt
> 	Pages		: 6
> 	Date		: 2005-10-17
> 	
>    This document define a Type-Length-Value format for 
> Cryptographically
>    Generated Address (CGA) Extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-cga-ext-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-cga-ext-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-cga-ext-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: Tue, 18 Oct 2005 08:31:22 +0000
Date: Tue, 18 Oct 2005 10:30:43 +0200
From: Olivier Bonaventure <[email-masked]>
To: [email-masked]
CC: Iljitsch van Beijnum <[email-masked]>, Cedric de Launois <[email-masked]>
Subject: Re: small stuff

Iljitsch,

> Then there are some other issues that I don't want to spend too much text on:

> 
> RTTs
> 
> 
> We had a discussion on whether measuring round trip times and basing decisions on the measurements is useful. I think it is. 

I also believe that delay is an important criteria in the selection of
the IPv6 addresses to be used for a communication.

> Delay is easy to measure, and all things being equal, a path with a long delay is less desireable than a path with a long delay. As I wrote last week, the queuing delay part in end-to-end delay is getting less and less important as bandwidth goes up.
> 
> And one of the main goals of being smart about reachability detection is avoid the really bad paths. As such continuing the reachability detection a bit longer if the delay looks worse than the previously looking path is an easy way to do this in many cases.
> 
> The argument that we shouldn't duplicate transport work doesn't convince me as we're lower in the stack and as such we get to see things (locator info) that is invisible to TCP and the like.

One issue with selecting the best local and distant addresses is that it
could required a large number of rtt measurements if done naively. This
is especially important when sites have more than two providers. In
today's Internet, multihomed stub ASes can have between 2 and 25 providers.

However, selecting the best pair of IPv6 addresses does not necessarily
require a large number of rtt measurements. In the peer-to-peer
literature, several papers have proposed coordinate systems. Basically,
the idea is that each host performs rtt measurements with a small number
of distant hosts (say a dozen). Based on those rtt measurements, each
host computes its coordinates (say (x,y)). The nice property of those
coordinates is that if you attach a coordinate to each IPv6 address,
then the distance between two coordinates is a good approximation of the
rtt between the two hosts. This means that by performing a few dozens of
rtt measurements, a host can predict the rtt towards *any* distant host.

Cédric de Launois developped such a coordinate system for his PhD
thesis. In his thesis, he shows that the coordinate system is stable and
the evaluation performed based on measurements obtained from the RIPE
Test Traffic project show that the rtt estimation is accurate. By using
a coordinate system, it is possible to avoid really bad paths and in
most cases, the path selected is the best one or very close to the best one.

You can find Cédric's thesis (Unleashing Traffic Engineering for IPv6
Multihomed Sites) on the web :
http://www2.info.ucl.ac.be/people/delaunoi/publications.html

Cédric also wrote an internet draft describing how coordinates could be
embedded in the DNS :
http://www2.info.ucl.ac.be/people/delaunoi/ietf/draft-de-launois-dnsext-sloc-rr-00.txt

I think that using a coordinate system to aid in the selection of
addresses, even as an option, would be a very insteresting addition to
the SHIM6 solution that is currently being developped.

Best regards,

Olivier Bonaventure

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

Delivery-date: Mon, 17 Oct 2005 16:16:56 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Date: Mon, 17 Oct 2005 17:47:46 +0200
To: Shinta Sugimoto <[email-masked]>

El 17/10/2005, a las 7:26, Shinta Sugimoto escribi=F3:
> Hmm.  I am not completely sure but I see slightly different issue with
> regard to the interaction between the ULP and shim6.  Let me try to
> explain that:
>
> I think ULP (or simply application) may want to decide whether to use
> shim6 or not.  In other words, whether if the application wants to =
have
> shim6 support for its flow.

agree

>  IMO, this decision is different from what
> is called ULID selection.

rigth

>  ULID selection is (if I understand it correctly)
> a choice of which ULID to use for particular flow.  As you mentioned,
> ULID selection can be made through source address selection.
>

right

> For instance, in MIP6, ULP may choose not to take advantage of MIP6 by
> specifying source address as one of the locators (CoA).  This is quite
> simple.  As far as the system provides a piece of information to
> distinguish HoA from the other IPv6 addresses, this would work. =20
> Although
> CoA and HoA are both in form of IPv6 address, they are distinct
> IP address (as far as the mobile is away from its home).
>

ok

> In comparison to the MIP6, situation is a bit different in shim6.

yes

> Although ULID and locator are conceptually different thing, ULID is
> at the same time one of locators.  This poses me following questions:
>
> Q1: Who decides which locator to be used as ULID ? (Shim6? ULP?)

ok, now i lost it
for now, all locators are ULIDs and all ULIDs are valid locators (we=20
are exploring the possibility of using ulids that are not valid=20
locators, but not there yet)

So, when the ULP selects the ulid, it is actually selecting the locator=20=

to be used initially as long as no failure occurs
through forking the ulp can change to other locator
After a failure, the shim selects the alternative locator to use, but=20
there are also forking here and also preferences

But i feel that this is not the point here. A i understood your point=20
above is that you think that it would be useful to allow a ULP to avoid=20=

using the shim for its traffic.
As i see it, this is not performed by selecting a given ULID or locator=20=

(as it would be in MIP, selecting the CoA)
Here as i see it we would need something else, for instance:
- an extended API (TBD) which allows ULP to indicate the shim that no=20
shim services are required for that flow
- configuration of the heuristics that trigger the shim establishment,=20=

so that the shim context is not established for those flows that use=20
certain apps (this is somehow limited, because in case that we have two=20=

apps, one that wants the shim and other that doesn't want it, then this=20=

mechanism wouldn't work, and we would need to use the API above)

[Please note that shim protocol as currently defined supports this. I=20
mean, because we are using the shim payload header to indicate if a=20
packet needs to be rewritten, we can have two apps using the same=20
locators, one of which need to be rewritten by the shim and the other=20
that doesn't requires locators to be rewritten.
for example, consider app1 uses A1 and B1 as ULIDs and locators.
Now consider app2, that uses A2 and B2 as ulids and locators.
Now suppose that app1 doesn't want to use the shim and that app2 does=20
want to use the shim.
so a shim context with ulids A2 and B2 is created and suppose that A1=20
and B1 are alternative locators for those ulids (for app2)
Now, for any reason, app2 traffic starts using A1 and B1 as locators
At this point, both app1 and app2 traffic would be flowing using A1 and=20=

B1 as addresses in the IPv6 packets. However, packets corresponding to=20=

app1 wouldn't carry the shim header so no need to rewrite while packets=20=

corresponding to app2 would carry the shim payload header, so they will=20=

be rewritten, so no proble with supporting one app traffic that don't=20
requires the shim. The only problem here is how the app indicates the=20
shim that it doens't want shim services, agree?]

>   - IMHO, it would make sense to let ULP to decide.  According
>     to the decision, shim6 takes care of context establishment.
>
> Q2: Who makes the ULID selection ?
>   - I agree that one choice would be to let ULP make selection
>     through source address selection. It would also possible of course
>     that ULP has no specific preference on which ULID to use, which=20
> will
>     result in kernel choosing the source address as defined in RFC=20
> 3484.
>
> To summarize, I think your comments are answers to Q2 above (actually
> its more than answers to Q2 but IMHO it does not cover answers to Q1).
> Taking look at Q1 from slightly different angle, I wonder how could
> application decide whether to request shim6 support or not.  What do=20=

> you
> think?
>

i think that this point is important, see above for the optins that i=20
can think of, do you have another idea of how this could be done?

regards, marcelo

Delivery-date: Mon, 17 Oct 2005 16:16:25 +0000
Cc: [email-masked], Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Date: Mon, 17 Oct 2005 18:01:42 +0200
To: Shinta Sugimoto <[email-masked]>

>
>>> - Section 1.5 discusses renumbering and its implications to shim. I 
>>> agree
>>>   that there is a serious concern with regard to the ownership of 
>>> ULID.
>>>   A host may intentionally/unintentionally claim invalid ULID which 
>>> is
>>>   actually owned by different node. CGA would solve this.
>>
>> It is actually more subtle than that.
>> Neither HBA nor CGA can prove ownership of the prefix part of the
>> address.
>
> You are right. The problem was not that simple...
> In HBA, secure binding between the set of prefixes and the HBAs
> is assured.  With CGA, a node can verify if the received packet
> was actually sent by the right peer.

well, thee proposed usage for cgas in shim is to sign alternative 
locators that are dynamic

>   With HBA/CGA, we can have
> both.  But the issue we are discussing here is how one can verify
> if the ULID is owned by the node which actually resides on the
> location (from network topology perspective) indicated by the ULID.

yes

>
>> Instead the shim uses a "probe" to verify that the ULID is
>> indeed present at the locator before sending packets to it.
>
> I believe you are referring to Reachability Probe message
> in shim6 ?  As far as I understand it, the message is for checking
> if the peer can be reachable with claimed locator.  Hence seems to
> me it's for solving a different issue.

above you mention that the issue being discussed is

      how one can verify if the ULID is owned by the
      node which actually resides on the location (from
      network topology perspective) indicated by the ULID.

through the reachability test, the sender includes in the reachability 
test the ULID and sends the probe to the new locator.
The receiver, will then verify if he owns the ulid before replying.
So through the reachability test, we are verifying that the owner of 
the ulid is located in the tested locator, right?

>
>> But the issue with renumbering is slightly different.
>> If A and B start communication using ULID pair <A1, B1>, this starts
>> using locators <A1, B1>. If there is a failure, the shim will switch 
>> to
>> using a different locator pair, say <A2, B1>.
>>
>> Now things might continue to work forever, using <A2, B1> as locators
>> and the ULP (e.g., TCP and the application> having ULID <A1, B1>.
>>
>> What happens if the site that A belongs to renumbers, so that A 
>> switches
>> from having {A1, A2}, to {A2, A3} as IP addresses?
>> The shim doesn't have to disrupt the traffic, since it is doing fine
>> using <A2, B1> as locators.
>> But could the ULP on B be confused when it sees packets from the new
>> "owner" of A1?
>> The fact that another host can now use ULID A1 could be a potential
>> issue, which would worst case suggest that the shim break the
>> communication when the ULID is removed from the host.
>
> I see it's difficult to handle a situation like above.  During the
> renumbering process, the old IP addresses should be deprecated,
> including ULID, IMHO.

deprecated means that the address should not be used for newer 
communications, but that can be used for ongoing communications, right?
So, a shim session that is using an address as ulid and that address is 
deprecated, the address can still be used as ulid for that ongoing 
session imho

> So probably shim6 should follow the direction
> of the lower layer in determining continuation of given ULID.  I
> didn't find any description about the ULID availability in protocol
> document.  For instance what would be expected behavior of shim6
> when ULID is become unavailable (i.e. preferred lifetime of the IPv6
> address (=ULID) has been expired) ?
>

preferred lifetime is not really the problem, imho, because the address 
can still be available. I guess the problem is what happens if the 
address is no longer valid (valid lifetime=0). We shouldn't use this 
address as a locator, but should we keep on using it as a ulid? here is 
where colision through renumbering may occur (with a very low 
probability)

if preferred lifetime = 0, then i guess that we could affect the 
preferences for that address within the shim, and if the address 
becomes invalid, then

regards, marcelo

>>
>>> - Section 5 provides details of the message formats.  Very basic 
>>> question
>>>   but why shim6 control message is designed as IPv6 extension header?
>>
>> So that the payload message fits.
>> I'll add this as an explanation in -02.
>
> Ok.
>
> [snip]
>
>
> Regards,
> Shinta
>
>

Delivery-date: Mon, 17 Oct 2005 10:08:05 +0000
Date: Mon, 17 Oct 2005 19:07:22 +0900
From: Shinta Sugimoto <[email-masked]>
To: Erik Nordmark <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Cc: [email-masked]

Hello Erik,

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

On Sun, 16 Oct 2005 15:59:43 -0700
Erik Nordmark <[email-masked]> wrote:

> Shinta Sugimoto wrote:
> > Hello,
> > 
> > I've read draft-ietf-shim6-proto-01.txt.  I found the document very
> > helpful to figure out how shim6 would work.  Please find my comments and
> > questions below:
> 
> Thanks for your comments.
> 
> >>   This implies that the ULID selection is performed as today's default
> >>   address  selection as specified in [11].  
> > 
> > 
> >   To me, what is stated in the last sentence does not seem to be an
> >   ideal case.  I believe it should be up to application whether to facilitate
> >   shim for a particular flow.  Current protocol document seems to be taking
> >   very flexible stance on how ULID is selected from the locators.
> >   However, from application standpoint, ULID selection is significant in
> >   a sense that IP transaction should be based on ULID if the application
> >   wants to preserve established communication taking advantage of shim.
> >   IMHO, upper layer protocol should be able to get involved in ULID selection,
> >   or at least, it should be able to distinguish ULID from the locators.
> 
> In the simple approach the ULID set is the same as the locator set, so 
> I'm not sure I understand what "distinguish" means in this case.
> [Some have argued for a mode where a host could create additional 
> locators that must never be used as ULIDs, but that isn't really simple.]
> 
> In any case, the DNS (in the AAAA records) contain addresses that can be 
> used as both ULIDs and locators.
> Once the the shim6 context is established between a pair of ULIDs, each 
> one of them will discover the set of locators of the peer (which might 
> be different than what was in the DNS.)
> 
> Does that make things more clear?

Yes. Thank you for the clarification.  But I still have unclear point.
My question is, in short, how the shim6 can be switched on/off
by ULP.  Such idea might be silly but let me try to explain that:

Suppose that a node A has address {A1,A2 and A3} and A1 is anyhow
selected as ULID.  In such case, app1 may want take advantage of shim6
and specify A1 as the source address for its flow.  OTOH, app2 may not
be requesting shim6 support at all.  How would the system allow app2 not
to use shim6 ?  Maybe app2 may avoid its flow to be shimmed by
specifying A2 or A3 as the source address.  But how come app2 know that
A1 is served as shim6 as ULID ?  Or is there any other mechanism which
allows ULP to switch on/off shim6 ?

> > - Section 1.5 discusses renumbering and its implications to shim. I agree
> >   that there is a serious concern with regard to the ownership of ULID.
> >   A host may intentionally/unintentionally claim invalid ULID which is
> >   actually owned by different node. CGA would solve this.
> 
> It is actually more subtle than that.
> Neither HBA nor CGA can prove ownership of the prefix part of the 
> address.

You are right. The problem was not that simple...
In HBA, secure binding between the set of prefixes and the HBAs
is assured.  With CGA, a node can verify if the received packet
was actually sent by the right peer.  With HBA/CGA, we can have
both.  But the issue we are discussing here is how one can verify
if the ULID is owned by the node which actually resides on the
location (from network topology perspective) indicated by the ULID.

> Instead the shim uses a "probe" to verify that the ULID is 
> indeed present at the locator before sending packets to it.

I believe you are referring to Reachability Probe message
in shim6 ?  As far as I understand it, the message is for checking
if the peer can be reachable with claimed locator.  Hence seems to
me it's for solving a different issue.

> But the issue with renumbering is slightly different.
> If A and B start communication using ULID pair <A1, B1>, this starts 
> using locators <A1, B1>. If there is a failure, the shim will switch to 
> using a different locator pair, say <A2, B1>.
> 
> Now things might continue to work forever, using <A2, B1> as locators 
> and the ULP (e.g., TCP and the application> having ULID <A1, B1>.
> 
> What happens if the site that A belongs to renumbers, so that A switches 
> from having {A1, A2}, to {A2, A3} as IP addresses?
> The shim doesn't have to disrupt the traffic, since it is doing fine 
> using <A2, B1> as locators.
> But could the ULP on B be confused when it sees packets from the new 
> "owner" of A1?
> The fact that another host can now use ULID A1 could be a potential 
> issue, which would worst case suggest that the shim break the 
> communication when the ULID is removed from the host.

I see it's difficult to handle a situation like above.  During the
renumbering process, the old IP addresses should be deprecated,
including ULID, IMHO.  So probably shim6 should follow the direction
of the lower layer in determining continuation of given ULID.  I
didn't find any description about the ULID availability in protocol
document.  For instance what would be expected behavior of shim6
when ULID is become unavailable (i.e. preferred lifetime of the IPv6
address (=ULID) has been expired) ?

> 
> > - Section 5 provides details of the message formats.  Very basic question
> >   but why shim6 control message is designed as IPv6 extension header?
> 
> So that the payload message fits.
> I'll add this as an explanation in -02.

Ok.

[snip]

Regards,
Shinta

Delivery-date: Mon, 17 Oct 2005 05:46:43 +0000
Date: Mon, 17 Oct 2005 15:45:36 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SHIM6 WG Agenda for IETF 64
Cc: kurt Erik Lindqvist <[email-masked]>, [email-masked], Erik Nordmark <[email-masked]>, [email-masked], [email-masked], [email-masked]

Hi,

As a followup to the call for agenda items made to this WG
on the 5th October, here's the draft agenda for the SHIM6 WG
meeting.

Its not too late yet to request items to be added to the agenda.
Please drop a note to Kurtis and myself if you have something
in mind.

thanks,

    Kurtis & Geoff

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

Site Multihoming by IPv6 Intermediation WG (SHIM6)

Friday, November 11 at 0900-1130
================================

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

AGENDA

1. Agenda Bashing, Victimization of scribe
                                     (5 minutes)

2. Review of Document Status and WG Roadmap
    Chairs
                                     (15 minutes)

3. Proposed changes to RFC 3484
    Marcelo Bagnulo

    Document:
       draft-bagnulo-shim6-addr-selection-00
       "Address selection in multihomed environments"
                                     (10 minutes)

4. HBA update
    Marcelo Bagnulo

    Document:
       draft-ietf-shim6-hba-00
       "Hash Based Addresses (HBA)"
                                     (5 minutes)

5. Protocol Specification  - outstanding issues
    Erik Nordmark

    Document:
       draft-ietf-shim6-proto-01
       "Level 3 multihoming shim protocol"
                                     (50 minutes)

6. Failure and Reacahability Detection - outstanding issues
    Jari Akko & Iljitsch van Beijnum

    Document:
       draft-ietf-shim6-failure-detection-01
       "Failure Detection and Locator Pair
        Exploration Design for IPv6 Multihoming"
                                     (50 minutes)

7. Other outstanding issues
    Chairs
                                     (20 minutes)

6. AOB

Recommended Reading:
   a) Minutes of the interim WG meeting
       http://www.potaroo.net/shim6/
   b) active wg documents to be discussed at the meeting
       draft-ietf-shim6-proto-01
       draft-ietf-shim6-failure-detection
   c) other documents whose status will be considered
       draft-ietf-shim6-hba-00.txt
       draft-bagnulo-shim6-addr-selection-00.txt
       draft-huitema-shim6-ingress-filtering-00.txt
   d) other shim6 documents that may be referred to
       draft--ietf-shim6-arch-00.txt
       draft-iietf-shim6-applicability-00.txt
       draft-ietf-shim6-applicability-00.txt

Delivery-date: Mon, 17 Oct 2005 05:27:02 +0000
Date: Mon, 17 Oct 2005 14:26:09 +0900
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Cc: [email-masked]

Hello Marcelo,

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

On Sat, 15 Oct 2005 18:46:32 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> Hi Shinta,
> 
> will try to address some of the points you bring...
> 
> El 14/10/2005, a las 11:21, Shinta Sugimoto escribis:
> 
> > Hello,
> >
> > I've read draft-ietf-shim6-proto-01.txt.  I found the document very
> > helpful to figure out how shim6 would work.  Please find my comments 
> > and
> > questions below:
> >
> > - From Section 1.3:
> >
> >>    Central to this approach is to not introduce a new identifier name
> >>    space but instead use one of the locators as the upper-layer ID,
> >>    while allowing the locators used in the address fields to change 
> >> over
> >>    time in response to failures of using the original locator.
> >>
> >>    This implies that the ULID selection is performed as today's 
> >> default
> >>    address  selection as specified in [11].
> >
> >   To me, what is stated in the last sentence does not seem to be an
> >   ideal case.  I believe it should be up to application whether to 
> > facilitate
> >   shim for a particular flow.  Current protocol document seems to be 
> > taking
> >   very flexible stance on how ULID is selected from the locators.
> >   However, from application standpoint, ULID selection is significant 
> > in
> >   a sense that IP transaction should be based on ULID if the 
> > application
> >   wants to preserve established communication taking advantage of shim.
> >   IMHO, upper layer protocol should be able to get involved in ULID 
> > selection,
> >   or at least, it should be able to distinguish ULID from the locators.
> >
> 
> While perhaps is not completely there I think this is exactly what is 
> being pursued in the spec...
> Let me try to expand on this:
> with the respect to the ULID selection, rfc3484 states that if the 
> application selects a given pair of src and dest address, this choice 
> must be honnoured, (as long as there is no problem with the scopes). 
> this behaviour is preserved here, meaning that if the app wants to 
> choose the ULID, it can. Of course, maybe there will be some apps that 
> will delegate to the lower layers to select the addresses, especially 
> the src address, in which case, the selection is performed below the 
> app

Ok, I agree with your statements above.

> 
> With respect to the locator selection, we can say that:
> - as long as the ULID is reachable, the ulid will be used as locator, 
> so selecting the ulid implies selecting the locator. so considering the 
> above comments, the app can choose the locators used at least before a 
> rehoming event, since it selects the ulid

Yes, it sounds reasonable.

> - after a rehoming event, the locators are selected by the shim. At 
> this point, the ulp can influence in the locator selection through 
> forking. Now, i think that so far the spec doesn't includes a full 
> description of how this is done, but the idea as i understand it is to 
> allow the ulp to indicate the shim which locators to use for different 
> flows. This would result in different apps using the same ulid pari, 
> but using different locator pairs. (please find the fork word through 
> the spec and see wome useful definitions about this point there)

Yes, application would definitely get involved in context forking in
which context is handled in finer granularity than ULID pairs.

> 
> I think that through these two techniques, the app can choose the ULID 
> and the locators used for the communication, obtaining quite a lot of 
> control of how packets are delivered through the shim...
> do you think that something else is needed?

Hmm.  I am not completely sure but I see slightly different issue with
regard to the interaction between the ULP and shim6.  Let me try to
explain that:

I think ULP (or simply application) may want to decide whether to use
shim6 or not.  In other words, whether if the application wants to have
shim6 support for its flow.  IMO, this decision is different from what
is called ULID selection.  ULID selection is (if I understand it correctly)
a choice of which ULID to use for particular flow.  As you mentioned,
ULID selection can be made through source address selection.

For instance, in MIP6, ULP may choose not to take advantage of MIP6 by
specifying source address as one of the locators (CoA).  This is quite
simple.  As far as the system provides a piece of information to
distinguish HoA from the other IPv6 addresses, this would work.  Although
CoA and HoA are both in form of IPv6 address, they are distinct
IP address (as far as the mobile is away from its home).

In comparison to the MIP6, situation is a bit different in shim6.
Although ULID and locator are conceptually different thing, ULID is
at the same time one of locators.  This poses me following questions:

Q1: Who decides which locator to be used as ULID ? (Shim6? ULP?)
  - IMHO, it would make sense to let ULP to decide.  According
    to the decision, shim6 takes care of context establishment.

Q2: Who makes the ULID selection ?
  - I agree that one choice would be to let ULP make selection
    through source address selection. It would also possible of course
    that ULP has no specific preference on which ULID to use, which will
    result in kernel choosing the source address as defined in RFC 3484.

To summarize, I think your comments are answers to Q2 above (actually
its more than answers to Q2 but IMHO it does not cover answers to Q1).
Taking look at Q1 from slightly different angle, I wonder how could
application decide whether to request shim6 support or not.  What do you
think?

> > - Section 1.5 discusses renumbering and its implications to shim. I 
> > agree
> >   that there is a serious concern with regard to the ownership of ULID.
> >   A host may intentionally/unintentionally claim invalid ULID which is
> >   actually owned by different node. CGA would solve this.
> >
> 
> 
> 
> > - Section 5 provides details of the message formats.  Very basic 
> > question
> >   but why shim6 control message is designed as IPv6 extension header?
> >
> 
> well, shim is a new layer in the stack (inside the ip layer) so as such 
> it needs a header to pass information

Yes.  Even though shim6 is conceptually a protocol inside the IP layer,
I think that shim6 header could be other than IPv6 extension header.
But I found the answer in Erik's email and some other documents.

> 
> >   I think the choice is reasonable.  Just curious about the motivation
> >   behind the design choice (piggyback?).
> 
> not sure what other options you where thinking here....
> the only other option that was discussed was using a new destination 
> option, but this was discarded because of problems related to how to 
> handle the destiantion option when multiple destiantion options are 
> there (i.e. ordering of the options, which one process first, how to 
> construct the destiantion option header when there are multiple sources 
> of destiantions options and the ordering would affect the resulting 
> behaviour)

I see.

> 
> >   As for payload message,
> >   there is no doubt that extension header is suitable to carry the
> >   context tag (better than using flowlabel).  Another comment about
> >   wording:  Current texts in Section 5, especially in the first 
> > paragraph,
> >   the design choice to use IPv6 extension header is not explicitly
> >   mentioned.  IMHO, it should be mentioned.
> >
> 
> yes, the idea is to try to summarize the design alternatives in an 
> appendix or separate document

Ok.

[snip]

Regards,
Shinta

Delivery-date: Sun, 16 Oct 2005 23:00:20 +0000
Date: Sun, 16 Oct 2005 15:59:43 -0700
From: Erik Nordmark <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-shim6-proto-01.txt

Shinta Sugimoto wrote:
> Hello,
> 
> I've read draft-ietf-shim6-proto-01.txt.  I found the document very
> helpful to figure out how shim6 would work.  Please find my comments and
> questions below:

Thanks for your comments.

>>   This implies that the ULID selection is performed as today's default
>>   address  selection as specified in [11].  
> 
> 
>   To me, what is stated in the last sentence does not seem to be an
>   ideal case.  I believe it should be up to application whether to facilitate
>   shim for a particular flow.  Current protocol document seems to be taking
>   very flexible stance on how ULID is selected from the locators.
>   However, from application standpoint, ULID selection is significant in
>   a sense that IP transaction should be based on ULID if the application
>   wants to preserve established communication taking advantage of shim.
>   IMHO, upper layer protocol should be able to get involved in ULID selection,
>   or at least, it should be able to distinguish ULID from the locators.

In the simple approach the ULID set is the same as the locator set, so 
I'm not sure I understand what "distinguish" means in this case.
[Some have argued for a mode where a host could create additional 
locators that must never be used as ULIDs, but that isn't really simple.]

In any case, the DNS (in the AAAA records) contain addresses that can be 
used as both ULIDs and locators.
Once the the shim6 context is established between a pair of ULIDs, each 
one of them will discover the set of locators of the peer (which might 
be different than what was in the DNS.)

Does that make things more clear?

> - Section 1.5 discusses renumbering and its implications to shim. I agree
>   that there is a serious concern with regard to the ownership of ULID.
>   A host may intentionally/unintentionally claim invalid ULID which is
>   actually owned by different node. CGA would solve this.

It is actually more subtle than that.
Neither HBA nor CGA can prove ownership of the prefix part of the 
address. Instead the shim uses a "probe" to verify that the ULID is 
indeed present at the locator before sending packets to it.

But the issue with renumbering is slightly different.
If A and B start communication using ULID pair <A1, B1>, this starts 
using locators <A1, B1>. If there is a failure, the shim will switch to 
using a different locator pair, say <A2, B1>.

Now things might continue to work forever, using <A2, B1> as locators 
and the ULP (e.g., TCP and the application> having ULID <A1, B1>.

What happens if the site that A belongs to renumbers, so that A switches 
from having {A1, A2}, to {A2, A3} as IP addresses?
The shim doesn't have to disrupt the traffic, since it is doing fine 
using <A2, B1> as locators.
But could the ULP on B be confused when it sees packets from the new 
"owner" of A1?
The fact that another host can now use ULID A1 could be a potential 
issue, which would worst case suggest that the shim break the 
communication when the ULID is removed from the host.

> - Section 5 provides details of the message formats.  Very basic question
>   but why shim6 control message is designed as IPv6 extension header?

So that the payload message fits.
I'll add this as an explanation in -02.

>   I think the choice is reasonable.  Just curious about the motivation
>   behind the design choice (piggyback?).  As for payload message,
>   there is no doubt that extension header is suitable to carry the
>   context tag (better than using flowlabel).  Another comment about
>   wording:  Current texts in Section 5, especially in the first paragraph,
>   the design choice to use IPv6 extension header is not explicitly
>   mentioned.  IMHO, it should be mentioned.

ok

> Why a bit followed by the Hdr Ext Len is set as "1" ? Is it for making
>   distinction between the payload message header and control header?
>   I think a description about this bit would be helpful for readers.

ok, I'll add that.

> - (This is rather editorial comment though) Section 14 and 15 provides
>   process of packet before/after the locator switch.  But I would
>   prefer to descriptions separated in terms of direction of the traffic
>   (inbound/outbound) rather than splitting before/after the locator
>   switch.

Good suggestion.

    Erik

Delivery-date: Sun, 16 Oct 2005 21:48:24 +0000
Date: Sun, 16 Oct 2005 23:48:12 +0200
From: Pierre Baume <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: about draft-ietf-shim6-proto-01.txt
Cc: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>

Hi Marcelo and all,

On 10/16/05, marcelo bagnulo braun <[email-masked]> wrote:
[...]

> In section 5.4  R1 Message Format
>
> It may make sense to allow the responder to include the locator set in
> the R1 message, so that the initiator can acknowledge the reception of
> the locator set (otherwise, the locator set of the responder is sent in
> R2 which remains unacknowledged).
> the potential problem with this is that an small I1 packet may result
> in a somehow big R1 packet which may be used by an attacker as an
> amplifier (but i am not sure whether this is a big issue, since the
> amplification won't be so important)

  Well, the attacker may choose an amplifier with a lot of locators.
And any amplification is bad anyway. ;-)

Pierre.

Delivery-date: Sun, 16 Oct 2005 21:46:32 +0000
Date: Sun, 16 Oct 2005 14:45:31 -0700
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Tony Hain <[email-masked]>, Daniel Karrenberg <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Second shim

Brian E Carpenter wrote:
> Erik Nordmark wrote:
> ...
> 
>> So while the application didn't specify it, and a "shim" or some new 
>> connect-by-name API can cycle through, it still will be a bit 
>> inefficient if you let TCP try things (for a single <source, dest>) 
>> and timing out before trying the next one.
> 
> 
> Yes, but quite tolerable for some applications (Lotus Notes seems to have
> done something very much like this for years, for example, and it's
> just fine for background replication).
> 
> I do wonder whether this isn't a distraction right now, though. It should
> certainly be orthogonal to the IP layer shim.

The question we asked ourselves at the interim meeting was whether the 
shim protocol needed some mechanism to facilitate solving the above 
problem above the shim layer. I think our conclusion is that if we can 
carry a ULID-pair option in the context establishment messages (I1 etc) 
then one can use the shim capability for these purposes (basically, to 
verify whether the ULID is reachable at a particular locator)  as part 
of some TBD API.

So in terms of getting the protocol spec finished I don't think we need 
to worry (any more) about this.

    Erik

Delivery-date: Sun, 16 Oct 2005 18:09:30 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-ietf-shim6-proto-01.txt
Date: Sun, 16 Oct 2005 20:08:33 +0200
To: Erik Nordmark <[email-masked]>

Hi,

i think that the document is improving rapidly, i send some comments 
below...

In section 1.6  Placement of the shim

    The proposal uses an multihoming shim layer within the IP layer,
    i.e., below the ULPs, as shown in Figure 1, in order to provide ULP
    independence.  The multihoming shim layer behaves as if it is
    associated with an extension header, which would be ordered
    immediately after any hop-by-hop options in the packet.

the shim header is placed after the routing header (and the associated 
destination options header) rather than immediately after than the 
hop-by-hop header (as mentioned in section 5.1)

In section 2.1  Definitions

    Host-pair context   The state that the multihoming shim maintains for
                        a particular peer.  The context is for a ULID
                        pair, as is identified by a context tag for each
                        direction.

I would rather use the expression shim-context rather than host pair 
context, because since each context is associated to a given ULID pair, 
there maybe more than one context for a given host pair, right? 
(moreover, as we consider the forking concept more in depth, there 
maybe more than one context for a given ulid pair) so using the vague 
expression shim context would suit to whatever extent this evolves to.
Similarly, i wouldn't say that the Host-pair context is" The state that 
the multihoming shim maintains for a particular peer." but rather  that 
it is the "The state that the multihoming shim maintains for a 
particular ULID pair." (at least for now)

In section 4.1  Context Tags

    The mechanism for detecting a loss of context state at the peer that
    is currently proposed in this document assumes that the receiver can
    tell the packets that need locator rewriting, even after it has lost
    all state (e.g., due to a crash followed by a reboot).

I would then add that this is achieved because after a rehoming event 
packets that need locator rewriting carry the Payload Message Header

    Even though we do not overload the flow label field to carry the
    context tag, any protocol (such as RSVP or NSIS) which signals
    information about flows from the host stack to devices in the path,
    need to be made aware of the locator agility introduced by a layer 3
    shim, so that the signaling can be performed for the locator pairs
    that are currently being used.

I would remove the first part of the sentence of this paragraph. I 
mean, in the future when people read the spec, they won't be familiar 
with our flow label discussions, so this initial part of the sentence 
may sound a bit strange to them imho.

In section 5.  Message Formats

I find the separation between the payload and control messages not 
really clarifying.
I mean the first paragraph in section 5 states that:

    The shim6 messages are all carried using a new IP protocol number TBD
    [to be assigned by IANA].  The shim6 messages have a common header,
    defined below, with some fixed fields, followed by type specific
    fields.

However, this common header is not presented, but instead, the payload 
message header and the common shim control header (which are different) 
are presented. (including this flag which changes from 0 in control 
messages to 1 in payload messages but that is not described explicitly 
in the doc)

I guess that the common shim header would be the following:

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |P|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

being P a flag that indicates whether this is a payload message (P set) 
or this is a control message (P reset)

and then the payload and control messages can be defined.

Then in section 5.2  Common Shim6 Control header

    The common part of the header has a next header and header extension
    length field which is consistent with the other IPv6 extension
    headers, even if the next header value is always "NO NEXT HEADER" for
    the control messages

but before this header there can be other header, right? like the 
routing header or hop-by-hop header.
My point is that this header is also located before
    any endpoint extension headers (fragmentation headers, destination
    options header, AH, ESP), but after any routing related headers (hop-
    by-hop extensions header, routing header, a destinations options
    header which precedes a routing header).
The difference is that for now, no piggybacking of ulp in the shim 
control messages is defined yet.
So i would state the location of the shim header and distinguish the 
case of payload messages where piggybacking of ulp is supported and 
control messages, where it is not.
This description would fit in the description of the common header 
(since it is always placed in the same place)

In section 5.4  R1 Message Format

It may make sense to allow the responder to include the locator set in 
the R1 message, so that the initiator can acknowledge the reception of 
the locator set (otherwise, the locator set of the responder is sent in 
R2 which remains unacknowledged).
the potential problem with this is that an small I1 packet may result 
in a somehow big R1 packet which may be used by an attacker as an 
amplifier (but i am not sure whether this is a big issue, since the 
amplification won't be so important)

In section 5.6  R2 Message Format

    CGA Parameter Data Structure: Included when the locator list is
                   included and the PDS was not included in the context
                   establishment messages, so the receiver can verify the
                   locator list.
This is kind of strange since this is one of the context establishment 
messages...
I guess it should read the same than in I2, i.e.

    CGA Parameter Data Structure: Included when the locator list is
                   included so the receiver can verify the locator list.

In section 5.8  Update Request Message Format

As i understand the locator set contained in this message contains the 
complete set of locators available, as opposed to including a 
differential list of what are the new locators to be added/removed to 
the locator list, right?
If this is so, i think this should be explicitly stated in this section.

In section 5.9  Update Acknowledgement Message Format

    This message is sent in response to a Update Request message.  It
    implies that the Update Request has been received, and that any new
    locators in the Update Request can now be used as the source locators
    of packets.  But it does not imply that the (new) locators have been
    verified

I am not sure what verifications are needed to accept a new locator as 
a valid src address and which is needed for using it as a valid dst 
address.
I mean, i clearly see that the reachability test used to prevent 
flooding attacks is required before using the new locator as dest 
address, but it is not needed before accepting packets with this 
locator as src address. But, are the HBA/CGA verifications required 
before accepting  packets with the new locator as src address? In other 
words, does the receiver of a update request message needs to perform 
HBA/CGA validation before sending the update ack packet?

Let's see this a bit more in detail... accepting packets from 
unverified locators in src address would allow an attacker to inject 
packets in a communication associated with a shim context, even though 
the peer will be still sending packets to the verified address. Of 
course for doing that, the attacker needs to determine the context tag, 
so it needs to have been on path once (and also need to use a sequence 
number in the locator update higher than the one currently used), so it 
doesn't seems so easy. However, accepting an unverified locator set may 
cause problems, in particular suppose that the attacker sends a packet 
with a very high seq number and the correct context tag, but it 
includes a locator list that contains all invalid locators. The victim 
accepts the list and substitutes the old (valid) list by the new 
(false) list. The result is a DoS attack, since there won't be any 
locator valid in the new list. Basically, accepting unverified lists of 
locators would enable time-shifted DoS attacks. This can be prevented 
by performing hba/cga verification before accepting the locator list. 
This has a cost though, since we need to make all the computation 
effort of verifying the locator list upon the reception of the list, 
even if we may not need the alternative locators ever.

In section 5.10  Reachability Probe Message Format

    This message includes the ULID pair as well as the context tag, so
    that the peer can indeed verify that it has that ULID and that the
    context tag is correct.

Just to keep in mind Iljitsch suggestion to be able to use a single 
reachability probe when multiple contexts were using the same locator 
pair, so that no multiple probes to the same locator pair are needed. 
For this, we need something different than simply the context tag and 
the ulid pair. Perhaps all the ulids and context tags of the involved 
context would be enough rather then move to new namespaces as 
hostids...

In section 5.14  Option Formats

it is stated that:

    Total Length = 11 + Length - (Length + 3) % 8;

wouldn't that be

    Total Length = 12 + Length - (Length + 4) % 8;

I mean, the length of the content of the option plus the type and 
length fields is: Length + 4, right?
so the padding needed is 8 - ((length + 4) Mod 8)
implying a total length of 12 + Length - (Length + 4) % 8... what did i 
got wrong?

In section 5.14.1  Validator Option Format

wouldn't it make sense to define different option types for different 
hash functions used for the validator? like 1 for sha1 validator, 2 for 
md5 and so on, so that different hash functions are supported? (and it 
is possible to move from one to another hash function by supporting 
many of them?

In section 5.14.3  Locator Preferences Option Format

I am not sure i fully understand the format of this option...

For instance, all elements have the same length i.e. the Element length 
field message applies to all the elements, or there is an Element 
Length field for each Element item that follows? (i think it is the 
first option, but the figure confuses me, because the Element[2] seems 
to have a different Length than Element[1] and Element[3]; other thing 
that confuses me about the figure is that the Element Length field 
seems to have variable length or 2 octets (because it has two rows))

In section 5.14.4  CGA Parameter Data Structure Option Format

    CGA Parameter Data Structure: Variable length content.  Content
                   defined in [5].

the format of the PDS is defined in RFC3972 and only the multiprefix 
extension is defined in [5]

In section 5.14.5  CGA Signature Option Format

    CGA Signature: Variable length content.  Content defined in [5].

The format of the CGA signature is defined in RFC3972. Besides, the 
signature defined in RFC3972 requires a 128-bit type tag for the 
message from the CGA Message Type name space that is specific to the 
usage of the CGA. In this case we would need to define such for shim 
and declare it in the IANA considerations, so that IANA assigns it. 
This 128 bit type tag is concatenated to what is being signed, so i 
guess this needs to be included here.
Furthermore, i guess we need to specify what is being signed here. I 
guess it doesn't makes sense to sign the whole locator list, since some 
of them are validated using HBAs. So a possible approach would be to 
extract from the locator list all of those that are validated through 
the CGA and sign those (ordered as they are included in the locator 
list),

So the string being signed would be:
the 128-bit type tag for the message from the CGA Message Type name 
space assigned to the shim plus that ordered list of locators that are 
validated using the CGA as they appear in the locator list of the 
update request message

In section 6.1  Conceptual Data Structures

    o  For each peer locator, a bit whether it has been validated using
       HBA,

i would add here "or CGA"
Moreover, perhaps we need a byte to indicate the validation method 
consistent with what is defined in the locator list option format

In section 7.5  Sending I1 messages

    If, after several retransmissions, there is no response, then most
    likely the peer does not implement the shim6 protocol, or there could
    be a firewall that blocks the protocol.

I guess that this depends on whether there is an ongoing communication 
or not. If there is an ongoing communication, then we can assume that 
the ulid is reachable, so if no answer is received then is because of 
any of the two above reasons. However, if there is not an ongoing 
communication or if a failure has just occurred, maybe it is that the 
ULID selected in unreachable and other locators/ULIDs should be tried. 
Not sure what to do in this case...

In section 9.  Handling ICMP Error Messages

    But when the shim on the transmitting side
    replaces the ULIDs in the IP address fields with some other locators,
    then an ICMP error coming back will have a "packet in error" which is
    not a packet that the ULP sent.  Thus the implementation will have to
    apply the reverse mapping to the "packet in error" before passing the
    ICMP error up to the ULP.

but the ICMP error won't have a shim payload header so, it won't be 
processed by the shim, right? or are we supposing that thee shim will 
inspect all packets (having the shim header or not) and identify ICMP 
error packets and in those inspect whther the inside packet contains a 
shim header and then do the processing?
I am especially concerned with the inspect all packets part, since i 
think i remeber talking in the meeting that this would result in 
important performance issues...

10.  Teardown of the Host Pair Context

    Each host can unilaterally decide when to tear down a host-pair
    context.  It is RECOMMENDED that hosts not tear down the context when
    they know that there is some upper layer protocol that might use the
    context.

Not sure i agree here. I recall Iljitsch suggestion that servers could 
tear down context prematurelly and leave up to the clients the recovery 
effort, using the context loss recovery mechanisms in order to reduce 
the load imposed by the shim. This sounds like a very nice approach to 
me. so i am not sure i agree with the reccomend here (perhaps i fail to 
see what the reccomend term implies...

Section 16.  Open Issues

    The following open issues are known:
    o  Is there need for keeping the list of locators private between the
       two communicating endpoints?  We can potentially accomplish that
       when using CGA but not with HBA, but it comes at the cost of doing
       some public key encryption and decryption operations as part of
       the context establishment.

I think that the option selected for this is a future extension of the 
protocol

    o  Forking the context state.  On the mailing list we've discussed
       the need to fork the context state, so that different ULP streams
       can be sent using different locator pairs.  No protocol extensions
       are needed if any forking is done independently by each endpoint.
       But if we want A to be able to tell B that certain traffic (a
       5-tuple?) should be forked, then we need a way to convey this in
       the shim6 protocol.  The hard part would be defining what
       selectors can be specified for the filter which determines which
       traffic uses which of the forks.  So the question is whether we
       really need signaling for forking, or whether it is sufficient to
       allow each endpoint to do its own selection of which locator pair
       it is using for which traffic.

imho for this what is needed is the capability of setting multiple 
context with the same ULID pair but with different context tags, and an 
API that allows the ulp to signal the shim which context is to be used 
(what the doc calls primary vs other contexts i think)

    o  If we allow forking, it seems like the mechanism for reachability
       detection, whether it is CUD or FBD, must be applied separately
       for each locator pair that is in use.  Without forking a single
       locator pair will be in use for each host-pair context, hence
       things would be simpler.
right, but this is a natural concequence, because we have multiple 
contexts now

    o  The specified mechanism (of relying on No Such Context errors)
       doesn't always detect the loss of the context on the peer when the
       original ULID=locators are used.  See Section 17 for other
       options.

since we are using the reactive strategy that allows the node to 
rcreate a shim state even after one end has lost it, then the only 
issue here is performance

    o  In the Locator List option, do we need to indicate which locators
       need to be validated using HBA vs. CGA?  Or it could tell which
       locators are in the HBA extension in the PDS, and assume any
       others need CGA validation.

the spec indicates which validation option is used for each, which is a 
good approach imho

20.  IANA Considerations

a CGA Message Type needs to be allocated for shim

Editorial

In the Abstract

    The SHIM6 working group is exploring a layer 3 shim approach for
    providing locator agility below the transport protocols, so that
    multihoming can be provided for IPv6 with failover and load spreading
    properties, without assuming that a multihomed site will have a
    provider independent IPv6 address which is announced in the global
    IPv6 routing table.

i would say "provider independent IPv6 address block" or "provider 
independent IPv6 address prefix"

In section 1.6  Placement of the shim

    Thus, effectively the
    multihoming shim layer is placed between the IP endpoint sublayer,
    which handles fragmentation, reassembly, and IPsec, and the IP
    routing sublayer, which on a host selects which default router to use
    etc.

s/which on/on which

In 2.1  Definitions

i would suggest to leave a blank line between each definition to 
improve readability

    address             An IP layer name that contains both topological
                        significance and acts as a unique identifier for
                        an interface. 128 bits.  This document only uses
                        the "address" term in the case where it isn't
                        specific whether it is a locator or a identifier.

s/a identifier/an identifier

    upper-layer identifier (ULID)
                        An IP locator which has been selected for
                        communication with a peer to be used by the upper
                        layer protocol.

i would prefer to say that the ulid is an address rather than a locator 
(seems clearer to me, and in the next paragraph is stated that in this 
case the ulid is also a valid locator)

    Current locator pair Each end of the context has a current locator
                        pair which is used to send packets to be peer.
                        The two ends might use different locator pairs
                        though.
s/The two ends might use different locator pairs/The two ends might use 
different current locator pairs

in section 4.1  Context Tags

    A context between two hosts is actually a context between two ULIDs.
    The context is identified by a pair of context tags.  Each end gets
    to allocate a context tag, and once the context is established, the
    shim6 control messages contain the context tag that the receiver of
    the message allocated.  Thus at a minimum the combination of <peer
    ULID, local ULID, local context> tag MUST uniquely identify one
    context.

s/local context> tag/local context tag>

in section 6.1  Conceptual Data Structures

    The key conceptual data structure for the shim6 protocol is the host
    pair context.  This is a data structures which contains the following
    information:

s/structures/structure

in section 7.3  Context recovery

    This need can arise in two cases:
       The communication is working using the ULID pair as the locator
       pair, but a problem arises, and the end that has retained the
       context state decides to explore alternate locator pairs.
       The communication is working using a locator pair that is not the
       ULID pair, hence the ULP packets sent from a peer that has
       retained the context state use the shim payload header.

I guess it would improve readability to include a this as a bulleted 
list (or a bank line separating the two items)

In section 7.4  Context confusion

    This type of "confusion" can be observed in two cases (assuming it is
    A that has retained the state and B has dropped it):
       B decides to create a context for ULID pair <A3, B1&gt, and
       allocates X as its context tag for this, and sends an I1 to A.
       A decides to create a context for ULID pair <A3, B1&gt, and starts
       the exchange by sending I1 to B. When B receives the I2 message,
       it allocates X as the context tag for this context.
    In both cases, A can detect that B has allocated X for ULID pair <A3,
    B1&gt even though that A still X as CT(peer) for ULID pair <A1,
    B1&gt.  Thus A can detect that B must have lost the context for <A1,
    B1&gt.

s/&gt/>
besides, putting the two cases in a bulleted list would be clearer imho

7.7  Receiving R1 messages

    When the host receives an R1 message, it verifies that the nonce
    matches what it sent in the I1 message, and that it has context state
    for the ULID pair.  It then sends an I2 message, which includes the
    verifier option that was in the R1 message.  The I2 message also
    includes A's locator list and the CGA parameter set.

s/CGA parameter set/CGA parameter data structure

    If CGA (and not
    HBA) is used to verify the locator list, then A also signs things and
    includes a CGA signature option.

sign "things" is maybe a bit too colloquial perhaps...

Delivery-date: Sun, 16 Oct 2005 13:36:33 +0000
Date: Sun, 16 Oct 2005 15:35:21 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: vijay gill <[email-masked]>
CC: David Meyer <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

vijay gill wrote:
> 
> 
> Brian E Carpenter wrote:
> 
>>>
>>> How then does the ISP perform any traffic engineering if all of the  
>>> control is in
>>> the end-host?  That needs a _lot_ of focus because ISPs aren't going  
>>> to put their
>>> COGS into the hands of their end users.
>>
>>
>> See the TLV discussion that Jason started. While I'm not sure he has
>> the right mechanism, there is definitely a requirement for hosts
>> to switch locators on request from a TE function as well as on outage.
>>
> 
> 
> I am assuming all hosts are hostile. Now what.

This is absolutely false on a corporate network, which is
a major use case for shim6. I know that may not be the context
that Nanog normally thinks about. Also, it will be in a subscriber's
best interests, I assume, to use the prefix that the ISP prefers,
in general. So I don't really see why hostility is relevant.

>>>
>>> Understood, but do not forget inbound path selection or weighting or  
>>> preference
>>> or whatever you want to call it.  That needs to be controllable from  
>>> the network
>>> level, not from the end hosts.
>>
>>
>> Yep. I think that is also a case where hosts will need to switch
>> on request.
>>
> 
> 
> They don't.

They don't *today* because there is no mechanism yet. We need
to provide it, and the first step is basic shim6.

    Brian

Delivery-date: Sat, 15 Oct 2005 16:50:31 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-01.txt
Date: Sat, 15 Oct 2005 18:46:32 +0200
To: Shinta Sugimoto <[email-masked]>

Hi Shinta,

will try to address some of the points you bring...

El 14/10/2005, a las 11:21, Shinta Sugimoto escribi=F3:

> Hello,
>
> I've read draft-ietf-shim6-proto-01.txt.  I found the document very
> helpful to figure out how shim6 would work.  Please find my comments=20=

> and
> questions below:
>
> - =46rom Section 1.3:
>
>>    Central to this approach is to not introduce a new identifier name
>>    space but instead use one of the locators as the upper-layer ID,
>>    while allowing the locators used in the address fields to change=20=

>> over
>>    time in response to failures of using the original locator.
>>
>>    This implies that the ULID selection is performed as today's=20
>> default
>>    address  selection as specified in [11].
>
>   To me, what is stated in the last sentence does not seem to be an
>   ideal case.  I believe it should be up to application whether to=20
> facilitate
>   shim for a particular flow.  Current protocol document seems to be=20=

> taking
>   very flexible stance on how ULID is selected from the locators.
>   However, from application standpoint, ULID selection is significant=20=

> in
>   a sense that IP transaction should be based on ULID if the=20
> application
>   wants to preserve established communication taking advantage of =
shim.
>   IMHO, upper layer protocol should be able to get involved in ULID=20
> selection,
>   or at least, it should be able to distinguish ULID from the =
locators.
>

While perhaps is not completely there I think this is exactly what is=20
being pursued in the spec...
Let me try to expand on this:
with the respect to the ULID selection, rfc3484 states that if the=20
application selects a given pair of src and dest address, this choice=20
must be honnoured, (as long as there is no problem with the scopes).=20
this behaviour is preserved here, meaning that if the app wants to=20
choose the ULID, it can. Of course, maybe there will be some apps that=20=

will delegate to the lower layers to select the addresses, especially=20
the src address, in which case, the selection is performed below the=20
app

With respect to the locator selection, we can say that:
- as long as the ULID is reachable, the ulid will be used as locator,=20
so selecting the ulid implies selecting the locator. so considering the=20=

above comments, the app can choose the locators used at least before a=20=

rehoming event, since it selects the ulid
- after a rehoming event, the locators are selected by the shim. At=20
this point, the ulp can influence in the locator selection through=20
forking. Now, i think that so far the spec doesn't includes a full=20
description of how this is done, but the idea as i understand it is to=20=

allow the ulp to indicate the shim which locators to use for different=20=

flows. This would result in different apps using the same ulid pari,=20
but using different locator pairs. (please find the fork word through=20
the spec and see wome useful definitions about this point there)

I think that through these two techniques, the app can choose the ULID=20=

and the locators used for the communication, obtaining quite a lot of=20
control of how packets are delivered through the shim...
do you think that something else is needed?

> - Section 1.5 discusses renumbering and its implications to shim. I=20
> agree
>   that there is a serious concern with regard to the ownership of =
ULID.
>   A host may intentionally/unintentionally claim invalid ULID which is
>   actually owned by different node. CGA would solve this.
>

> - Section 5 provides details of the message formats.  Very basic=20
> question
>   but why shim6 control message is designed as IPv6 extension header?
>

well, shim is a new layer in the stack (inside the ip layer) so as such=20=

it needs a header to pass information

>   I think the choice is reasonable.  Just curious about the motivation
>   behind the design choice (piggyback?).

not sure what other options you where thinking here....
the only other option that was discussed was using a new destination=20
option, but this was discarded because of problems related to how to=20
handle the destiantion option when multiple destiantion options are=20
there (i.e. ordering of the options, which one process first, how to=20
construct the destiantion option header when there are multiple sources=20=

of destiantions options and the ordering would affect the resulting=20
behaviour)

>   As for payload message,
>   there is no doubt that extension header is suitable to carry the
>   context tag (better than using flowlabel).  Another comment about
>   wording:  Current texts in Section 5, especially in the first=20
> paragraph,
>   the design choice to use IPv6 extension header is not explicitly
>   mentioned.  IMHO, it should be mentioned.
>

yes, the idea is to try to summarize the design alternatives in an=20
appendix or separate document

> - Section 5.1 gives description about payload message format.
>
>>    2), there is a choice whether the shim applies inside the tunnel =
or
>>    outside the tunnel, which effects the location of the shim6 =
header.
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Next Header  |       0       |1|       Reserved              |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                      Receiver Context Tag                     |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>
>   Why a bit followed by the Hdr Ext Len is set as "1" ? Is it for=20
> making
>   distinction between the payload message header and control header?

right

>   I think a description about this bit would be helpful for readers.
>

agree

regards, marcelo

> - (This is rather editorial comment though) Section 14 and 15 provides
>   process of packet before/after the locator switch.  But I would
>   prefer to descriptions separated in terms of direction of the =
traffic
>   (inbound/outbound) rather than splitting before/after the locator
>   switch.
>
>
> Regards,
> Shinta
>
>

Delivery-date: Fri, 14 Oct 2005 18:24:26 +0000
Date: Fri, 14 Oct 2005 14:23:28 -0400
From: vijay gill <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: David Meyer <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

Brian E Carpenter wrote:

>>
>> How then does the ISP perform any traffic engineering if all of the  
>> control is in
>> the end-host?  That needs a _lot_ of focus because ISPs aren't going  
>> to put their
>> COGS into the hands of their end users.
> 
> See the TLV discussion that Jason started. While I'm not sure he has
> the right mechanism, there is definitely a requirement for hosts
> to switch locators on request from a TE function as well as on outage.
> 

I am assuming all hosts are hostile. Now what.

>>
>> Understood, but do not forget inbound path selection or weighting or  
>> preference
>> or whatever you want to call it.  That needs to be controllable from  
>> the network
>> level, not from the end hosts.
> 
> Yep. I think that is also a case where hosts will need to switch
> on request.
> 

They don't.

/vijay

Delivery-date: Fri, 14 Oct 2005 13:13:30 +0000
Date: Fri, 14 Oct 2005 15:13:19 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: shim header in every shimmed packet

Before trying to make this work, which seems to me at least as hard
as making the abandoned flow label solution work, I'd like to know
whether ROHC couldn't be used.

    Brian

Iljitsch van Beijnum wrote:
> On 12-okt-2005, at 12:09, Erik Nordmark wrote:
> 
>>> And of course, it doesn't get any simpler than simply putting in  an  
>>> explicit shim6 header with the context tag in every shimmed  packet.  
>>> This is what's on the table now.
> 
> 
>> Iljitsch,
>> it is not in every packet.
>> It is only in packets after a locator switch i.e., when the IPv6  
>> source and/or destination are different then the ULIDs.
> 
> 
> That's what I meant with "every shimmed packet".
> 
>> Looks like you are assuming that there will be failures all the  time 
>> so that NO packet will have ULIDs=locators.
> 
> 
> Of course not. Most packets will not be rewritten by the shim.
> 
> However, when this capability becomes common it's not inconceivable  
> that people are going to let it catch stuff that is now repaired  
> differently, so that rewriting becomes more common that it would seem  
> extrapolating the current situation.
> 
> And of course there is traffic engineering, which may lead to a  fairly 
> large amount of rewriting.
> 
>> Isn't the receiver's ability to demux the packets to the correct  
>> context without the context tag a function of the locator sets and  
>> ULIDs that are in use?
>> If so I don't see how a single bit can suffice.
> 
> 
>> It seems like one would need to at a minimum covey that bit in the  
>> Update Ack message (in addition to the context establishment) so  that 
>> when the peer changes its locators, the host can restate  whether or 
>> not it can demux without the context tag for the new set  of locators.
> 
> 
> Right. I haven't thought much about the issues around locator  updating 
> because I was kind of assuming this wouldn't happen in the  presense of 
> HBA.
> 
>> But the current design also uses uncoordinated teardown of the  
>> context state, which can result in one end not having any context  
>> state any more, even though the peer might send packets using that  
>> context.
>> With the context tag in the packets that need to be rewritten by  the 
>> receiver, we can detect this condition. But your 'single bit'  scheme 
>> would seem to need some different way to detect this missing  state. 
>> Any ideas on how to do this?
> 
> 
> That would be something that we explore in the "how to safely  suppress 
> the shim header after rewriting" document but in the case  where the 
> locator sets for the different ULIDs are disjoint this  isn't an issue: 
> the receiver without state that receives a shimmed  packet without a 
> shim header will know this because the packet is  addressed at a 
> locator-only address. It can then either send back a  shim error or an 
> ICMP error.
> 

Delivery-date: Fri, 14 Oct 2005 13:08:35 +0000
Date: Fri, 14 Oct 2005 15:08:16 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Erik Nordmark <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Tony Hain <[email-masked]>, Daniel Karrenberg <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Second shim

Erik Nordmark wrote:
...
> So while the application didn't specify it, and a "shim" or some new 
> connect-by-name API can cycle through, it still will be a bit 
> inefficient if you let TCP try things (for a single <source, dest>) and 
> timing out before trying the next one.

Yes, but quite tolerable for some applications (Lotus Notes seems to have
done something very much like this for years, for example, and it's
just fine for background replication).

I do wonder whether this isn't a distraction right now, though. It should
certainly be orthogonal to the IP layer shim.

    Brian

Delivery-date: Fri, 14 Oct 2005 13:04:29 +0000
Date: Fri, 14 Oct 2005 15:03:42 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: John Payne <[email-masked]>
CC: "Jason Schiller ([email-masked])" <[email-masked]>, Mohacsi Janos <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, David Meyer <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

John Payne wrote:
> 
> On Oct 11, 2005, at 4:04 AM, Brian E Carpenter wrote:
> 
>>> Do you think that operators of commercial networks will want to  
>>> switch to
>>> shim6?
>>>
>>
>> They won't need to. Shim6 deploys in the hosts. An ISP doesn't have
>> to do a single thing to enable or switch to shim6. Customer sites with
>> two PA prefixes will just start multihoming. That's the beauty
>> of it.
> 
> 
> Except for ISPs who are too small to get their own prefix....

Right.

> 
> 
>> A local ISP might decide to facilitate shim6 for the benefit of its  
>> customers
>> (i.e. the ISP plus its subscribers becomes a "site" in shim6  terms). 
>> That
>> ISP would indeed have to do something, but not much - advertise two  
>> prefixes
>> to its customers, who would thereby get 2N addresses where they had N
>> addresses before. Shim6 would do the rest in the hosts.
> 
> 
> How then does the ISP perform any traffic engineering if all of the  
> control is in
> the end-host?  That needs a _lot_ of focus because ISPs aren't going  to 
> put their
> COGS into the hands of their end users.

See the TLV discussion that Jason started. While I'm not sure he has
the right mechanism, there is definitely a requirement for hosts
to switch locators on request from a TE function as well as on outage.

> 
> 
>> [In both cases I've skimmed over exit router selection issues, which
>> still needs work.]
> 
> 
> Understood, but do not forget inbound path selection or weighting or  
> preference
> or whatever you want to call it.  That needs to be controllable from  
> the network
> level, not from the end hosts.

Yep. I think that is also a case where hosts will need to switch
on request.

> 
>>> Consider the current comfort level with the IPv4 style BGP
>>> de-aggregate traffic engineering.  Consider that the current  
>>> approach to
>>> shim6 is less functional than the current IPv4 style multi-homing.
>>>
>>
>> I don't think that's true, from the requirements viewpoint
>> of the end user.
> 
> 
> I don't care about the end user's requirements so much as the ISP's  
> requirements.
> The ISPs are the ones that need to manage cost, so they need tools  
> equivalent to
> what they have today.

Understood, but the IETF is supposed to balance everybody's interests -
not just the ISPs', not just the end users'.

> 
> 
>>> Consider the the shim6 solution may be very different to operate
>>> (configuring end hosts instead of Internet facing routers)
>>>
>>
>> No configuration involved. Just a shim6 capable stack.
> 
> 
> That's oversimplifying it, surely?  With no consideration to (again)  
> traffic
> engineering, I can believe the lack of configuration... but with  
> traffic engineering,
> *something* needs to be configured.

Hopefully only in the TE system itself, but I'm assuming a non-existent
mechanism for distributing address selection policy to hosts. I do agree that
is an open requirement today.

> 
>>> and may
>>> break current operational boundaries.
>>>
>>
>> It seems more likely to make them irrelevant, to me.
> 
> 
> Some would see that as a problem.

Busines model issue, I guess.

> 
>> There's a big difference between what major sites with the weight to
>> get their prefix advertised can do and what small and medium  businesses
>> without such weight can do. I don't doubt that a few thousand major
>> corporations will end up with PI-like solutions. I know that won't  
>> happen
>> for tens of millions of small and medium businesses. I hope that ARIN
>> and all the RIRs move very carefully, for that reason.
> 
> 
> Something like "you can get PI space if you have an ASN, when we run  
> out of ASNs
> you run out of luck" ?

Well, we can easily fix the supply of ASNs. I think that when the
operators start yelling for that, the IETF and vendors know what to do.

But yes, PI doesn't scale. That's been known for ten years and I don't
see any new inventions that will change it.

    Brian

Delivery-date: Fri, 14 Oct 2005 09:22:51 +0000
Date: Fri, 14 Oct 2005 18:21:52 +0900
From: Shinta Sugimoto <[email-masked]>
To: [email-masked]
Subject: comments on draft-ietf-shim6-proto-01.txt

Hello,

I've read draft-ietf-shim6-proto-01.txt.  I found the document very
helpful to figure out how shim6 would work.  Please find my comments and
questions below:

- From Section 1.3:

>    Central to this approach is to not introduce a new identifier name
>    space but instead use one of the locators as the upper-layer ID,
>    while allowing the locators used in the address fields to change over
>    time in response to failures of using the original locator.
> 
>    This implies that the ULID selection is performed as today's default
>    address  selection as specified in [11].  

  To me, what is stated in the last sentence does not seem to be an
  ideal case.  I believe it should be up to application whether to facilitate
  shim for a particular flow.  Current protocol document seems to be taking
  very flexible stance on how ULID is selected from the locators.
  However, from application standpoint, ULID selection is significant in
  a sense that IP transaction should be based on ULID if the application
  wants to preserve established communication taking advantage of shim.
  IMHO, upper layer protocol should be able to get involved in ULID selection,
  or at least, it should be able to distinguish ULID from the locators.

- Section 1.5 discusses renumbering and its implications to shim. I agree
  that there is a serious concern with regard to the ownership of ULID.
  A host may intentionally/unintentionally claim invalid ULID which is
  actually owned by different node. CGA would solve this.

- Section 5 provides details of the message formats.  Very basic question
  but why shim6 control message is designed as IPv6 extension header?
  I think the choice is reasonable.  Just curious about the motivation
  behind the design choice (piggyback?).  As for payload message,
  there is no doubt that extension header is suitable to carry the
  context tag (better than using flowlabel).  Another comment about
  wording:  Current texts in Section 5, especially in the first paragraph,
  the design choice to use IPv6 extension header is not explicitly
  mentioned.  IMHO, it should be mentioned.

- Section 5.1 gives description about payload message format.

>    2), there is a choice whether the shim applies inside the tunnel or
>    outside the tunnel, which effects the location of the shim6 header.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |       0       |1|       Reserved              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Receiver Context Tag                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 

  Why a bit followed by the Hdr Ext Len is set as "1" ? Is it for making
  distinction between the payload message header and control header?
  I think a description about this bit would be helpful for readers.

- (This is rather editorial comment though) Section 14 and 15 provides
  process of packet before/after the locator switch.  But I would
  prefer to descriptions separated in terms of direction of the traffic
  (inbound/outbound) rather than splitting before/after the locator
  switch.

Regards,
Shinta

Delivery-date: Thu, 13 Oct 2005 07:05:06 +0000
Date: Thu, 13 Oct 2005 16:06:09 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-proto-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           : Level 3 multihoming shim protocol
         Author(s)       : E. Nordmark
         Filename        : draft-ietf-shim6-proto-01.txt
         Pages           : 52
         Date            : 2005-10-12

The SHIM6 working group is exploring a layer 3 shim approach for
    providing locator agility below the transport protocols, so that
    multihoming can be provided for IPv6 with failover and load spreading
    properties, without assuming that a multihomed site will have a
    provider independent IPv6 address which is announced in the global
    IPv6 routing table.  The hosts in a site which has multiple provider
    allocated IPv6 address prefixes, will use the shim6 protocol
    specified in this document to setup state with peer hosts, so that
    the state can later be used to failover to a different locator pair,
    should the original one stop working.

    This document picks a particular approach to such a protocol and
    tries to flush out a bunch of details, with the hope that the WG can
    better understand the details in this proposal as well as discovering
    and understanding alternative designs that might be better.  Thus
    this proposal is my no means cast in stone as the direction; quite to
    the contrary it is a depth first exploration of the design space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-01.txt

Delivery-date: Thu, 13 Oct 2005 07:05:05 +0000
Date: Thu, 13 Oct 2005 16:01:24 +1000
To: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: shim header in every shimmed packet

At 12:51 AM 13/10/2005, Iljitsch van Beijnum wrote:
>On 12-okt-2005, at 16:35, marcelo bagnulo braun wrote:
>
>>My question is: do you want that those additional mechanisms are
>>included in the base shim spec (not the bit that signals that the
>>shim header is needed or not, the actual mechanisms) or it is good
>>enough for you that those can be specified in a different document?
>
>I prefer to have the mechanisms required to be able to safely enable
>suppression of the shim header in a different document.

And Erik responded:

>Right. I haven't thought much about the issues around locator  updating 
>because I was kind of assuming this wouldn't happen in the  presense of HBA.

 > But it can with CGA.

[...]

 > It seems to me that we can't make sure the we got the handling of
 > the "bit" correct until we know how the sender and receiver will
 > use this capability.

Thanks for this. One approach for the next steps for a "different document" 
is to generate a draft that describes this in detail, and, of course, 
submit it to the WG for potential adoption as a WG document.

Is this what we can anticipate? If so, when would you anticipate such a 
document being submitted to the ietf drafts repository? Is it 
conditional  on locator set updating being specified, as referred to by Erik?

regards,

     Geoff

Delivery-date: Thu, 13 Oct 2005 05:49:06 +0000
Date: Wed, 12 Oct 2005 22:49:09 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: the small stuff

Iljitsch van Beijnum wrote:

> Forking
> 
> Somehow the assumption crept in that we need to support "context  
> forking". The trouble with this is that there are two or more context  
> for communication between the same ULID pair. This is problematic  
> because now packets must somehow be tagged on their way through the  
> stack from the application to the shim so the shim knows which  context 
> to apply, based on the wishes of the application.
> 
> I don't really see the advantages here. The idea is that this is  useful 
> so different applications can take different paths through the  
> networks. I have no problem with that, but doing it inside the shim  is 
> a rathole: applications should just select the ULIDs associated  with 
> the desired path. The shim mechanism can then be relegated to  repairing 
> failures, and maybe provide some coarse traffic engineering  at the most.
> 
> It might be useful to add a shim exchange that can support selecting  
> the right ULIDs in this case, though: that would be fairly light-weight.

That would be an option.

My understanding is that the request to be able to do forking (which 
we've interpreted as different ULP traffic being able to use different 
locator pairs to get to the same destination host), was requested by 
some transport folks.

I don't know if we have a mechanism to ask them (whoever they were) 
whether it is acceptable to do this using a ULID selection mechanism, or 
whether the ULIDs should be the same but the locators different.
In either case, the ULP needs to be updated to be capable to make the 
shim setup forked context, so I assume there is some flexibility on 
their end.

> Length fields
> 
> I'm not happy with 16 bit length fields or length fields expressed in  
> 64-bit/8-byte units because of padding issues. In the latter case,  
> padding to an even 8 bytes will always be required which is very  
> inconvenient for fields with variable length content. Also, a 16-bit  
> field would either require padding or sometimes straddle 16-bit  
> boundaries, which means the two bytes must be extracted individually  
> and then be glued together to form a 16-bit field again.
> 
> If we only need longer fields for a very small number of variables,  
> it's easier to redefine these variables so that they are broken in  
> 255-byte chunks and put in two or more fields.

This is an issue for the shim control messages. They need to be able to 
carry
  - lists of locators
  - CGA parameter data structure
  - CGA public key signature
and I think we concluded that at least the last one might be larger than 
256 bytes. But I don't know how large the PDS might be.

However, I don't think there will be any significant difference in the 
size of these shim control messages if we relax the alignment rules for 
the options and make the length field be a single byte.
I'm not personally concerned with saving a few bytes in a control 
message that might be a few hundred bytes.

> Checksums
> 
> We didn't get a chance to discuss the issues surrounding the upper  
> layer checksum. As I've said before, I think we're best off rewriting  
> the TCP/UDP checksums along with the addresses. If we don't do this,  
> transport checksum calculation offloading will be a big problem in  
> IPv6. The potential for harmful actions from firewalls and such that  
> don't see a valid checksum is also significant. Howevever, this is  
> somewhat related to the suppressing of the shim header issue.

And as I've said before, I think this is a very bad idea.
In some cases, such as ESP, the shim might not be able to rewrite the 
TCP checksum. So if we were to do this, then we'd end up with the 
semantics of the checksum field being different depending on what 
extension headers are in place.

I don't understand the statement which ends win "big problem in IPv6".
Are you assuming that a lot of packets will be sent with a locator pair 
that is different than the ULID pair?
I think failures are and will be infrequent, so the fraction of shim 
capable traffic which will be sent with a locator pair that is different 
than the ULID pair will be vanishingly small.
When the ULID pair == locator pair, the packets are exactly as today, so 
any checksum offloading will work.

And there are ways to do checksum offloading that is flexible enough to 
even handle the (infrequent) case of ULID pair != locator pair.

> Demux on source with shim header
> 
> A question we also didn't get to explore is on which fields we use to  
> recognize a shim context when the shim header is present. I think the  
> assumption has been source/context tag/dest. Since the number of  
> destination addresses is very small and the sets are going to  overlap, 
> we may as well toss out the destination address. If we also  throw out 
> the source address and do demux on just the context, this  means we 
> don't have to synchronize knowledge of the source locators  on both 
> ends. (I.e., without this the source can only successfully  use a 
> locator when the destination knows it should expect this  locator.) And 
> it allows source address rewriting by routers. The  protocol number for 
> the shim header should be enough to tell the  router that this is ok, so 
> there is no ambiguity in this decision. On  the other hand this means 
> attackers can try to spoof the context tag  without needing to get 
> source address right. So essentially we're  giving up on ingress 
> filtering for the most part.

I think that *if* we want to keep the door open to routers rewriting the 
source address field, then we should seriously consider 1) expanding the 
context tag to 47 bits and 2) look at the security impact of not using 
the source address as part of the lookup of the context on the receiver.

But I don't get the feeling that the WG has come to consensus on whether 
we want to consider having routers rewriting the source address.

    Erik

Delivery-date: Thu, 13 Oct 2005 05:07:33 +0000
Date: Wed, 12 Oct 2005 22:07:16 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, Tony Hain <[email-masked]>, Daniel Karrenberg <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: Second shim

marcelo bagnulo braun wrote:

> In scenario 1, the ULID and the locator used for the communication need 
> to be the same since the peer does not support the translation, so, 
> using a different ULID that the locator used would break things.
> In this case, what we need would be the upgraded RFC3484 which would 
> allow to cycle through different source addresses.
> However, i would like to note some part of RFC3484:
> 
>    The application might also specify a source address
>    with bind(), but often the source address is left unspecified.
>    Therefore the network layer does often choose a source address from
>    several alternatives.
> ...
>    Separately, the IPv6 network layer will use the source address
>    selection algorithm when an application or upper-layer has not
>    specified a source address.
> 
> So this basically says that in very common scenarios, is actually the IP 
> layer that selects the source address. In this case, then it would be 
> possible to build additional mechanisms within the IP layer that when a 
> packet with unspecified source address is received, it tries different 
> source addresses and uses the one that seems to be working (we still 
> need to understand what does "seems to be working means though..)

While the IP layer might select it, and this might be helpful for UDP, 
the TCP case works different in practice. TCP ends up asking the IP 
layer for which source address to use as part of TCP creating the tcb, 
which is done before the SYN packet is sent out.

So while the application didn't specify it, and a "shim" or some new 
connect-by-name API can cycle through, it still will be a bit 
inefficient if you let TCP try things (for a single <source, dest>) and 
timing out before trying the next one.

    Erik

Delivery-date: Thu, 13 Oct 2005 02:48:29 +0000
Date: Wed, 12 Oct 2005 19:48:12 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: shim header in every shimmed packet

Iljitsch van Beijnum wrote:

> Right. I haven't thought much about the issues around locator  updating 
> because I was kind of assuming this wouldn't happen in the  presense of 
> HBA.

But it can with CGA.

>> But the current design also uses uncoordinated teardown of the  
>> context state, which can result in one end not having any context  
>> state any more, even though the peer might send packets using that  
>> context.
>> With the context tag in the packets that need to be rewritten by  the 
>> receiver, we can detect this condition. But your 'single bit'  scheme 
>> would seem to need some different way to detect this missing  state. 
>> Any ideas on how to do this?
> 
> 
> That would be something that we explore in the "how to safely  suppress 
> the shim header after rewriting" document but in the case  where the 
> locator sets for the different ULIDs are disjoint this  isn't an issue: 
> the receiver without state that receives a shimmed  packet without a 
> shim header will know this because the packet is  addressed at a 
> locator-only address. It can then either send back a  shim error or an 
> ICMP error.

Yes, but I thought we wanted the capability to do this in other cases 
than the disjoint case (I've never been a fan of each host that has N 
ULIDs needing to create (N*N - N) extra locators).

It seems to me that we can't make sure the we got the handling of the 
"bit" correct until we know how the sender and receiver will use this 
capability.

    Erik

Delivery-date: Wed, 12 Oct 2005 14:51:55 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 16:51:03 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-okt-2005, at 16:35, marcelo bagnulo braun wrote:

> My question is: do you want that those additional mechanisms are  
> included in the base shim spec (not the bit that signals that the  
> shim header is needed or not, the actual mechanisms) or it is good  
> enough for you that those can be specified in a different document?

I prefer to have the mechanisms required to be able to safely enable  
suppression of the shim header in a different document.

Delivery-date: Wed, 12 Oct 2005 14:36:31 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 16:35:29 +0200
To: Iljitsch van Beijnum <[email-masked]>

Ok, wihtout discussing the merits of this approach, it is certain that=20=

it needs additional mechanisms to work, like to enable the host to=20
identify that a new context is being setup and that this context cannot=20=

be distinguished without that an additional context tag so that the=20
shim header is needed and so on.
My question is: do you want that those additional mechanisms are=20
included in the base shim spec (not the bit that signals that the shim=20=

header is needed or not, the actual mechanisms) or it is good enough=20
for you that those can be specified in a different document?

regards, marcelo

El 12/10/2005, a las 16:10, Iljitsch van Beijnum escribi=F3:

> On 12-okt-2005, at 15:29, marcelo bagnulo braun wrote:
>
>> right, but as was noted, a single bit is not enough for demux, so an=20=

>> alternative context tag is needed.
>
> No, I don't believe this is necessarily the case. I can imagine=20
> different ways to accomplish this, but let me just describe the=20
> simplest one.
>
> Hosts A and B communicate. A has addresses A1 and A2. In the case of B=20=

> it's a bit more complex: B has ULID/locator addresses B1 and B2, but=20=

> these aren't valid locators for each other: B1 has the alternative=20
> locator B1' and B2 has the alternative locator B2'.
>
> The chosen ULIDs for a TCP session are A1-B1. However, at some point=20=

> B1 fails and the communication is rerouted to A2-B1'. The context has=20=

> tag X but therere is no shim header in the packets flowing from A to=20=

> B.
>
> When B receives a packet, it can recognize that this is a shimmed=20
> packet because the locator B1' is present. B then goes looking for a=20=

> context with ULID B1 on B's side and locator A2 at the remote side.=20
> Since there is only one such context B finds the X context, rewrites=20=

> the addresses and the packet is handed over to TCP.
>
> Now if an application tries to set up a session from A2 to B1, when A=20=

> tries to set up a new context Y B notices that this context and the=20
> existing A1-B1 can't be disambiguated without a shim header so it=20
> tells A to use the header for this context.
>
> A2-B1' packets without a header are then still mapped to context X=20
> while packets belonging to context Y are recognizable as such by their=20=

> context tag in the shim header.
>

Delivery-date: Wed, 12 Oct 2005 14:20:40 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 16:19:49 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-okt-2005, at 15:29, marcelo bagnulo braun wrote:

> right, but as was noted, a single bit is not enough for demux, so  
> an alternative context tag is needed.

The bit isn't in packets, it's used to tell the other side that  
including the shim in packets isn't necessary.

Delivery-date: Wed, 12 Oct 2005 14:11:02 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 16:10:03 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-okt-2005, at 15:29, marcelo bagnulo braun wrote:

> right, but as was noted, a single bit is not enough for demux, so  
> an alternative context tag is needed.

No, I don't believe this is necessarily the case. I can imagine  
different ways to accomplish this, but let me just describe the  
simplest one.

Hosts A and B communicate. A has addresses A1 and A2. In the case of  
B it's a bit more complex: B has ULID/locator addresses B1 and B2,  
but these aren't valid locators for each other: B1 has the  
alternative locator B1' and B2 has the alternative locator B2'.

The chosen ULIDs for a TCP session are A1-B1. However, at some point  
B1 fails and the communication is rerouted to A2-B1'. The context has  
tag X but therere is no shim header in the packets flowing from A to B.

When B receives a packet, it can recognize that this is a shimmed  
packet because the locator B1' is present. B then goes looking for a  
context with ULID B1 on B's side and locator A2 at the remote side.  
Since there is only one such context B finds the X context, rewrites  
the addresses and the packet is handed over to TCP.

Now if an application tries to set up a session from A2 to B1, when A  
tries to set up a new context Y B notices that this context and the  
existing A1-B1 can't be disambiguated without a shim header so it  
tells A to use the header for this context.

A2-B1' packets without a header are then still mapped to context X  
while packets belonging to context Y are recognizable as such by  
their context tag in the shim header.

Delivery-date: Wed, 12 Oct 2005 13:58:58 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: the small stuff
Date: Wed, 12 Oct 2005 15:58:03 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/10/2005, a las 14:39, Iljitsch van Beijnum escribi=F3:

> Then there are some other issues that I don't want to spend too much=20=

> text on:
>
> Forking
>
> Somehow the assumption crept in that we need to support "context=20
> forking". The trouble with this is that there are two or more context=20=

> for communication between the same ULID pair. This is problematic=20
> because now packets must somehow be tagged on their way through the=20
> stack from the application to the shim so the shim knows which context=20=

> to apply, based on the wishes of the application.
>
> I don't really see the advantages here. The idea is that this is=20
> useful so different applications can take different paths through the=20=

> networks. I have no problem with that, but doing it inside the shim is=20=

> a rathole: applications should just select the ULIDs associated with=20=

> the desired path. The shim mechanism can then be relegated to=20
> repairing failures, and maybe provide some coarse traffic engineering=20=

> at the most.
>

right, this seems a possible option indeed
OTOH, my last understanding of what forking was (the concept seemed to=20=

change quite rapidly during the meeting :-) was simply the possibility=20=

to create multiple context with the same ULID pair. Those context would=20=

have different context tags, so no problem with distinguish among them.
So, i think that if, this is what we are talking when we say forking, i=20=

don't see that it would be to complicated, since having different=20
context tags would deal with it fairly easily

> It might be useful to add a shim exchange that can support selecting=20=

> the right ULIDs in this case, though: that would be fairly=20
> light-weight.
>
> RTTs
>
> We had a discussion on whether measuring round trip times and basing=20=

> decisions on the measurements is useful. I think it is. Delay is easy=20=

> to measure, and all things being equal, a path with a long delay is=20
> less desireable than a path with a long delay. As I wrote last week,=20=

> the queuing delay part in end-to-end delay is getting less and less=20
> important as bandwidth goes up.
>
> And one of the main goals of being smart about reachability detection=20=

> is avoid the really bad paths. As such continuing the reachability=20
> detection a bit longer if the delay looks worse than the previously=20
> looking path is an easy way to do this in many cases.
>
> The argument that we shouldn't duplicate transport work doesn't=20
> convince me as we're lower in the stack and as such we get to see=20
> things (locator info) that is invisible to TCP and the like.
>

Well, my understanding of the proposed approach and the reasons for it=20=

was somehow different:
first of all, RTT time measured in one or two packets (i.e. path=20
exploration packets) didn't seem to be representative of the real RTT=20
of the path.
Second, there are other metrics that seemed at least as relevant than=20
the RTT
third and most important, using the RTT for selecting paths does not=20
requires coordination from both ends, and can be adopted unilaterally.=20=

Clearly, having the RTT measured and taken into account into address=20
pair selection would indeed be more complex. So, the approach proposed=20=

was to include simpler path selection mechanisms in the core spec, but=20=

allow extensions for taking RTT into account for selecting paths in=20
other documents

> Length fields
>
> I'm not happy with 16 bit length fields or length fields expressed in=20=

> 64-bit/8-byte units because of padding issues. In the latter case,=20
> padding to an even 8 bytes will always be required which is very=20
> inconvenient for fields with variable length content. Also, a 16-bit=20=

> field would either require padding or sometimes straddle 16-bit=20
> boundaries, which means the two bytes must be extracted individually=20=

> and then be glued together to form a 16-bit field again.
>
> If we only need longer fields for a very small number of variables,=20
> it's easier to redefine these variables so that they are broken in=20
> 255-byte chunks and put in two or more fields.
>
> Checksums
>
> We didn't get a chance to discuss the issues surrounding the upper=20
> layer checksum. As I've said before, I think we're best off rewriting=20=

> the TCP/UDP checksums along with the addresses. If we don't do this,=20=

> transport checksum calculation offloading will be a big problem in=20
> IPv6. The potential for harmful actions from firewalls and such that=20=

> don't see a valid checksum is also significant. Howevever, this is=20
> somewhat related to the suppressing of the shim header issue.
>
> Demux on source with shim header
>
> A question we also didn't get to explore is on which fields we use to=20=

> recognize a shim context when the shim header is present. I think the=20=

> assumption has been source/context tag/dest.

Not sure about this...
the context tag is assigned by the receiver, so i would argue that the=20=

context tag is unique for that receiver (i.e. for all the incoming=20
packets)
This is easy because since the context tag is now quite big, no problem=20=

with running out of them
so in this case, the context tag is enough to identify the context at=20
the receiver.
then we verify that the addresses are valid for that context, but this=20=

is for security, rather than because we need that info for demux.

> Since the number of destination addresses is very small and the sets=20=

> are going to overlap, we may as well toss out the destination address.=20=

> If we also throw out the source address and do demux on just the=20
> context, this means we don't have to synchronize knowledge of the=20
> source locators on both ends. (I.e., without this the source can only=20=

> successfully use a locator when the destination knows it should expect=20=

> this locator.)

right, but the problem with this is about security. An attacker could=20
send packets with its own source address and insert them inside a shim=20=

communication, by just guessing the context tag.
This would result in additional vulnerabilities because it would allow=20=

the attacker to workaround ingress filters i.e. no need to send a=20
spoofed source address, which could be difficult for the attacker=20
because ingress filters.

>  And it allows source address rewriting by routers. The protocol=20
> number for the shim header should be enough to tell the router that=20
> this is ok, so there is no ambiguity in this decision. On the other=20
> hand this means attackers can try to spoof the context tag without=20
> needing to get source address right. So essentially we're giving up on=20=

> ingress filtering for the most part.
>
> Hostid
>
> We had a long discussion on having a hostid in the meeting. I don't=20
> think this was really resolved, either why we need it or why we=20
> wouldn't want it. I'll keep an eye open for these issues when I go=20
> over the details of the reachability protocol I proposed to see=20
> whether it needs a hostid, but it would be useful if someone could=20
> outline the reasons we should avoid having one.
>

as i understood, the goal that you were after when proposing using=20
hostids was recognized as important (allowing to share path exploration=20=

messages through multiple contexts)
The problem with hostids is that we need to define them with the=20
correspondent complexity of defining a new name for the host. So=20
alternatives mechanisms to achieve the goal that you proposed were=20
explored.
Not really a problem with hostids, just looking if there are simpler=20
options to achieve the same without defining a new name

regards, marcelo

Delivery-date: Wed, 12 Oct 2005 13:33:05 +0000
Cc: Tony Hain <[email-masked]>, Daniel Karrenberg <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Second shim
Date: Wed, 12 Oct 2005 15:26:54 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/10/2005, a las 11:55, Iljitsch van Beijnum escribi=F3:

> I had a conversation with Tony Hain and Daniel Karrenberg yesterday,=20=

> where we discussed the issues with the shim and very short-lived=20
> sessions such as single packet UDP request/reply interactions.
>
> This ties in with the "failure of the initially chosen locators" issue=20=

> that we talked about. I think it was Daniel who brought up the need=20
> for a "second shim" that sits between the application and the=20
> transport protocol that could handle this need.
>
> I think that makes a lot of sense. The current shim is all about=20
> keeping ULP sessions flowing within the constraint of keeping the=20
> ULIDs stable. But in a single packet interaction there is no need to=20=

> keep ULIDs "stable": you can just try different source/dest addresses=20=

> and retry the transaction until it works.
>
> I think the current presumption is that the application itself would=20=

> do this. However, for what the shim as it is now _does_ do, the idea=20=

> is that the shim's activities are completely hidden from applications=20=

> and ULPs. So it makes sense to consider the possibilities of allowing=20=

> current applications using current APIs to survive initial failures.
>
> I'm not talking about single packet UDP stuff anymore: for our=20
> purposes, a TCP connection establishment is pretty much also an=20
> exchange of a handful of packets. It's only after the session=20
> establishes and the application starts sending/receiving data that TCP=20=

> and the like are constrained by the requirement that the addresses=20
> remain stable. However, at this point the shim as currently intended=20=

> can take over so that's not a problem.
>
> It would work as follows. The "second shim" intercepts session=20
> establishement requests (bind(), connect() and the like) along with=20
> the sending of UDP packets (sendto(), sendmsg()). The second shim then=20=

> first tries the requested action using the addresses supplied by the=20=

> application and/or RFC 3484 address selection mechanisms. When this=20
> action times out, the second shim looks up additional addresses (see=20=

> below) and tries all source/dest combinations until something works.=20=

> At that point the whole thing is handed back to the calling=20
> application and the second shim gets out of the way.
>

First of all, i think it is important to exactly identify the scenario=20=

that we are considering. I can see two scenarios here:
- Scenario 1: the host that is initiating the communication supports=20
some multihoming specific mechanisms but the peer is just a legacy IPv6=20=

host (no special multihoming support)
- Scenario 2: both hosts involved in the communication support=20
multihoming specific mechanisms (like the second shim that you are=20
talking about)

In scenario 1, the ULID and the locator used for the communication need=20=

to be the same since the peer does not support the translation, so,=20
using a different ULID that the locator used would break things.
In this case, what we need would be the upgraded RFC3484 which would=20
allow to cycle through different source addresses.
However, i would like to note some part of RFC3484:

    The application might also specify a source address
    with bind(), but often the source address is left unspecified.
    Therefore the network layer does often choose a source address from
    several alternatives.
...
    Separately, the IPv6 network layer will use the source address
    selection algorithm when an application or upper-layer has not
    specified a source address.

So this basically says that in very common scenarios, is actually the=20
IP layer that selects the source address. In this case, then it would=20
be possible to build additional mechanisms within the IP layer that=20
when a packet with unspecified source address is received, it tries=20
different source addresses and uses the one that seems to be working=20
(we still need to understand what does "seems to be working means=20
though..)

I mean, that updated RFC3484 could provide enhanced mechanisms to=20
perform source address selection when the application leaves the source=20=

address unspecified, that would allow to try multiple source addresses
Perhaps this mechanisms would also work for legacy hosts (hosts that=20
don't support the updated RFC3484) sicne it will only require support=20
from the initiating host, that should try multiple source addresses

This behavior would be transparent for ulp as long as they don't=20
specify the source address. If the source address is specified, then=20
the app should cycle through different source and destination=20
addresses. This seems to be coherent with the fact that the app is=20
specifying the source address

In the second scenario, is what i understood that we called API on=20
steroids in the interim meeting, where the app asks to connect with a=20
given ulid and the shim will ask the resolver for the additional=20
addresses that the resolver obtained for that particular query, and=20
tries to connect using different locators, but keeping the same ULID.
This would cope with some failures but we need to keep in mind that=20
different addresses associated with a given FQDN may belong to=20
different hosts. this means that the shim needs to ask if the=20
alternative locator used belongs to the same host that the used ULID
Actually, this is not good as it may seem, because maybe, it is=20
possible that there are no working locators for that particular ULID,=20
but that other addresses that are asociated with the same FQDN but that=20=

belong to a different host (hence cannot be used as locatros for the=20
selected ULID) are working
In this case, it would be the application that needs to retry with a=20
different ULID; but in this case, the shim could inform about which=20
ulid to try first since it already knows which ones are working.

So, as we talked in the interim meeting, i guess that what is needed is:

- Updated RFC3484 to deal with legacy hosts and to cope with apps that=20=

left the source address unspecified
- API on steroids, to deal with apps that want to keep  the ulid fixed
- signaling from the shim to the ulp so that when the ulid selected is=20=

not working, information about which combinatiosn are working is passed

regards, marcelo

Delivery-date: Wed, 12 Oct 2005 13:32:34 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 15:29:47 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/10/2005, a las 11:29, Iljitsch van Beijnum escribi=F3:

>
> What I want is:
>
> - one bit (or whatever makes sense after we look at the details) that=20=

> a host can use to tell its correspondent that it doesn't want to see a=20=

> shim header in incoming packets for the context in question
> - when indicated by the bit and within some constraints (for instance,=20=

> there are no intermediate headers between the IPv6 header and the=20
> ULP), hosts implementing the spec are REQUIRED to leave out the shim=20=

> header for packets belonging to this context

right, but as was noted, a single bit is not enough for demux, so an=20
alternative context tag is needed.
The specification of the alternative context tag would be in the core=20
doc or in the separate document?

> - advice that hosts SHOULD set the bit such that the shim header is=20
> sent
>
> Under which circumstances the shim header can safely be left out so=20
> hosts can set/clear the bit can then be explored in a separate=20
> document.
>

and the alternative mechanisms for demux, i.e. alternative context=20
tags, are also in this separated document?

Regards, marcelo

Delivery-date: Wed, 12 Oct 2005 12:40:23 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: the small stuff
Date: Wed, 12 Oct 2005 14:39:30 +0200

Then there are some other issues that I don't want to spend too much  
text on:

Forking

Somehow the assumption crept in that we need to support "context  
forking". The trouble with this is that there are two or more context  
for communication between the same ULID pair. This is problematic  
because now packets must somehow be tagged on their way through the  
stack from the application to the shim so the shim knows which  
context to apply, based on the wishes of the application.

I don't really see the advantages here. The idea is that this is  
useful so different applications can take different paths through the  
networks. I have no problem with that, but doing it inside the shim  
is a rathole: applications should just select the ULIDs associated  
with the desired path. The shim mechanism can then be relegated to  
repairing failures, and maybe provide some coarse traffic engineering  
at the most.

It might be useful to add a shim exchange that can support selecting  
the right ULIDs in this case, though: that would be fairly light-weight.

RTTs

We had a discussion on whether measuring round trip times and basing  
decisions on the measurements is useful. I think it is. Delay is easy  
to measure, and all things being equal, a path with a long delay is  
less desireable than a path with a long delay. As I wrote last week,  
the queuing delay part in end-to-end delay is getting less and less  
important as bandwidth goes up.

And one of the main goals of being smart about reachability detection  
is avoid the really bad paths. As such continuing the reachability  
detection a bit longer if the delay looks worse than the previously  
looking path is an easy way to do this in many cases.

The argument that we shouldn't duplicate transport work doesn't  
convince me as we're lower in the stack and as such we get to see  
things (locator info) that is invisible to TCP and the like.

Length fields

I'm not happy with 16 bit length fields or length fields expressed in  
64-bit/8-byte units because of padding issues. In the latter case,  
padding to an even 8 bytes will always be required which is very  
inconvenient for fields with variable length content. Also, a 16-bit  
field would either require padding or sometimes straddle 16-bit  
boundaries, which means the two bytes must be extracted individually  
and then be glued together to form a 16-bit field again.

If we only need longer fields for a very small number of variables,  
it's easier to redefine these variables so that they are broken in  
255-byte chunks and put in two or more fields.

Checksums

We didn't get a chance to discuss the issues surrounding the upper  
layer checksum. As I've said before, I think we're best off rewriting  
the TCP/UDP checksums along with the addresses. If we don't do this,  
transport checksum calculation offloading will be a big problem in  
IPv6. The potential for harmful actions from firewalls and such that  
don't see a valid checksum is also significant. Howevever, this is  
somewhat related to the suppressing of the shim header issue.

Demux on source with shim header

A question we also didn't get to explore is on which fields we use to  
recognize a shim context when the shim header is present. I think the  
assumption has been source/context tag/dest. Since the number of  
destination addresses is very small and the sets are going to  
overlap, we may as well toss out the destination address. If we also  
throw out the source address and do demux on just the context, this  
means we don't have to synchronize knowledge of the source locators  
on both ends. (I.e., without this the source can only successfully  
use a locator when the destination knows it should expect this  
locator.) And it allows source address rewriting by routers. The  
protocol number for the shim header should be enough to tell the  
router that this is ok, so there is no ambiguity in this decision. On  
the other hand this means attackers can try to spoof the context tag  
without needing to get source address right. So essentially we're  
giving up on ingress filtering for the most part.

Hostid

We had a long discussion on having a hostid in the meeting. I don't  
think this was really resolved, either why we need it or why we  
wouldn't want it. I'll keep an eye open for these issues when I go  
over the details of the reachability protocol I proposed to see  
whether it needs a hostid, but it would be useful if someone could  
outline the reasons we should avoid having one.

Delivery-date: Wed, 12 Oct 2005 12:15:32 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Second shim
Date: Wed, 12 Oct 2005 14:14:32 +0200
To: Jari Arkko <[email-masked]>

On 12-okt-2005, at 12:48, Jari Arkko wrote:

> What would be the difference between the "second
> shim" and the actions of the "updated RFC 3484" that
> we talked about in Amsterdam? Does the latter
> impact applications? I thought not, but I may be
> mistaken.

RFC 3484 says that applications should cycle through all the  
destination addresses it provides. So applications need to do this  
work. When this is extended to source addresses too the application  
will have to cycle through all source/dest pairs. This means a  
significant impact on applications.

If we can put a shim between the sendto, sendmsg, bind and connect  
API calls and the actual execution of the underlying mechanisms then  
this can be handled transparently to the application.

A new sendto/sendmsg/bind/connect-by-name API extension could do the  
same but that of course also require application changes...

Delivery-date: Wed, 12 Oct 2005 12:09:37 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 14:08:18 +0200
To: Erik Nordmark <[email-masked]>

On 12-okt-2005, at 12:09, Erik Nordmark wrote:

>> And of course, it doesn't get any simpler than simply putting in  
>> an  explicit shim6 header with the context tag in every shimmed  
>> packet.  This is what's on the table now.

> Iljitsch,
> it is not in every packet.
> It is only in packets after a locator switch i.e., when the IPv6  
> source and/or destination are different then the ULIDs.

That's what I meant with "every shimmed packet".

> Looks like you are assuming that there will be failures all the  
> time so that NO packet will have ULIDs=locators.

Of course not. Most packets will not be rewritten by the shim.

However, when this capability becomes common it's not inconceivable  
that people are going to let it catch stuff that is now repaired  
differently, so that rewriting becomes more common that it would seem  
extrapolating the current situation.

And of course there is traffic engineering, which may lead to a  
fairly large amount of rewriting.

> Isn't the receiver's ability to demux the packets to the correct  
> context without the context tag a function of the locator sets and  
> ULIDs that are in use?
> If so I don't see how a single bit can suffice.

> It seems like one would need to at a minimum covey that bit in the  
> Update Ack message (in addition to the context establishment) so  
> that when the peer changes its locators, the host can restate  
> whether or not it can demux without the context tag for the new set  
> of locators.

Right. I haven't thought much about the issues around locator  
updating because I was kind of assuming this wouldn't happen in the  
presense of HBA.

> But the current design also uses uncoordinated teardown of the  
> context state, which can result in one end not having any context  
> state any more, even though the peer might send packets using that  
> context.
> With the context tag in the packets that need to be rewritten by  
> the receiver, we can detect this condition. But your 'single bit'  
> scheme would seem to need some different way to detect this missing  
> state. Any ideas on how to do this?

That would be something that we explore in the "how to safely  
suppress the shim header after rewriting" document but in the case  
where the locator sets for the different ULIDs are disjoint this  
isn't an issue: the receiver without state that receives a shimmed  
packet without a shim header will know this because the packet is  
addressed at a locator-only address. It can then either send back a  
shim error or an ICMP error.

Delivery-date: Wed, 12 Oct 2005 10:48:45 +0000
Date: Wed, 12 Oct 2005 13:48:18 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: Second shim

What would be the difference between the "second
shim" and the actions of the "updated RFC 3484" that
we talked about in Amsterdam? Does the latter
impact applications? I thought not, but I may be
mistaken.

--Jari

Iljitsch van Beijnum wrote:

> I had a conversation with Tony Hain and Daniel Karrenberg yesterday,  
> where we discussed the issues with the shim and very short-lived  
> sessions such as single packet UDP request/reply interactions.
>
> This ties in with the "failure of the initially chosen locators"  
> issue that we talked about. I think it was Daniel who brought up the  
> need for a "second shim" that sits between the application and the  
> transport protocol that could handle this need.
>
> I think that makes a lot of sense. The current shim is all about  
> keeping ULP sessions flowing within the constraint of keeping the  
> ULIDs stable. But in a single packet interaction there is no need to  
> keep ULIDs "stable": you can just try different source/dest addresses  
> and retry the transaction until it works.
>
> I think the current presumption is that the application itself would  
> do this. However, for what the shim as it is now _does_ do, the idea  
> is that the shim's activities are completely hidden from applications  
> and ULPs. So it makes sense to consider the possibilities of allowing  
> current applications using current APIs to survive initial failures.
>
> I'm not talking about single packet UDP stuff anymore: for our  
> purposes, a TCP connection establishment is pretty much also an  
> exchange of a handful of packets. It's only after the session  
> establishes and the application starts sending/receiving data that  
> TCP and the like are constrained by the requirement that the  
> addresses remain stable. However, at this point the shim as currently  
> intended can take over so that's not a problem.
>
> It would work as follows. The "second shim" intercepts session  
> establishement requests (bind(), connect() and the like) along with  
> the sending of UDP packets (sendto(), sendmsg()). The second shim  
> then first tries the requested action using the addresses supplied by  
> the application and/or RFC 3484 address selection mechanisms. When  
> this action times out, the second shim looks up additional addresses  
> (see below) and tries all source/dest combinations until something  
> works. At that point the whole thing is handed back to the calling  
> application and the second shim gets out of the way.
>
> Finding additional addresses is a challenge of its own, but a good  
> start would be o look up the destination address supplied by the  
> application in the DNS, and then look up all AAAA records for the  
> resulting name. Whether these addresses are all present on the same  
> host or they are for different hosts implementing the same service is  
> of no importance at this point.
>
> There is the slight caveat that hosts will now connect to a different  
> address than they thought they were connecting to. A weak version of  
> the second shim would leave the destination address untouched but  
> only cycle through the available source addresses if the application  
> specifies IN6ADDR_ANY (yes, yes, I know, this doesn't exist as such).  
> In practice we'll probably want some management hooks that allow the  
> administrator to specify whcih application/protocols get which  
> treatment.
>
> Thoughts?
>
>
>

Delivery-date: Wed, 12 Oct 2005 10:46:47 +0000
Date: Wed, 12 Oct 2005 13:46:10 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: shim header in every shimmed packet

I see the engineering desire to make this work better,
but feel that optimizing the failure case (beyond not
killing sessions) may be too much complexity for
too little gain.

--Jari

Delivery-date: Wed, 12 Oct 2005 10:09:54 +0000
Date: Wed, 12 Oct 2005 03:09:23 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: shim header in every shimmed packet

Iljitsch van Beijnum wrote:

> And of course, it doesn't get any simpler than simply putting in an  
> explicit shim6 header with the context tag in every shimmed packet.  
> This is what's on the table now.

Iljitsch,
it is not in every packet.
It is only in packets after a locator switch i.e., when the IPv6 source 
and/or destination are different then the ULIDs.

> The question is of course whether saving 8 bytes on shimmed packets  is 
> worth the trouble relative to the added complexity of having  packets 
> with or without the header. It looks that to a large degree,  this is a 
> matter of personal taste. We're essentially increasing  overhead on IPv6 
> by at least 1% (7.7% to 8.7%  for two 1500 byte TCP  packets + an ACK). 

Looks like you are assuming that there will be failures all the time so 
that NO packet will have ULIDs=locators. If that level of failures was 
common in the Internet today, then I suspect we'd spend most of our time 
waiting for BGP to converge instead of sending emails to each other :-)

 > So in these cases it makes sense to suppress the shim header. Now
 > obviously it may be tricky to determine exactly when the receiver  will
 > or won't need the shim header, but the good part is that we  don't have
 > to figure that out now. What I'm arguing for is a  capability that
 > allows a receiver to let the sender know it doesn't  need the shim
 > header for a certain context (when there are no  extension headers). So
 > the only thing we need is specify a capability  bit in the initial shim
 > exchange that signals this, and require that  implementations suppress
 > the shim header when the bit indicates this  is desired.

Isn't the receiver's ability to demux the packets to the correct context 
without the context tag a function of the locator sets and ULIDs that 
are in use?
If so I don't see how a single bit can suffice.

It seems like one would need to at a minimum covey that bit in the 
Update Ack message (in addition to the context establishment) so that 
when the peer changes its locators, the host can restate whether or not 
it can demux without the context tag for the new set of locators.

But the current design also uses uncoordinated teardown of the context 
state, which can result in one end not having any context state any 
more, even though the peer might send packets using that context.
With the context tag in the packets that need to be rewritten by the 
receiver, we can detect this condition. But your 'single bit' scheme 
would seem to need some different way to detect this missing state. Any 
ideas on how to do this?

    Erik

Delivery-date: Wed, 12 Oct 2005 09:56:34 +0000
Cc: Daniel Karrenberg <[email-masked]>, Tony Hain <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Second shim
Date: Wed, 12 Oct 2005 11:55:34 +0200
To: shim6-wg <[email-masked]>

I had a conversation with Tony Hain and Daniel Karrenberg yesterday,  
where we discussed the issues with the shim and very short-lived  
sessions such as single packet UDP request/reply interactions.

This ties in with the "failure of the initially chosen locators"  
issue that we talked about. I think it was Daniel who brought up the  
need for a "second shim" that sits between the application and the  
transport protocol that could handle this need.

I think that makes a lot of sense. The current shim is all about  
keeping ULP sessions flowing within the constraint of keeping the  
ULIDs stable. But in a single packet interaction there is no need to  
keep ULIDs "stable": you can just try different source/dest addresses  
and retry the transaction until it works.

I think the current presumption is that the application itself would  
do this. However, for what the shim as it is now _does_ do, the idea  
is that the shim's activities are completely hidden from applications  
and ULPs. So it makes sense to consider the possibilities of allowing  
current applications using current APIs to survive initial failures.

I'm not talking about single packet UDP stuff anymore: for our  
purposes, a TCP connection establishment is pretty much also an  
exchange of a handful of packets. It's only after the session  
establishes and the application starts sending/receiving data that  
TCP and the like are constrained by the requirement that the  
addresses remain stable. However, at this point the shim as currently  
intended can take over so that's not a problem.

It would work as follows. The "second shim" intercepts session  
establishement requests (bind(), connect() and the like) along with  
the sending of UDP packets (sendto(), sendmsg()). The second shim  
then first tries the requested action using the addresses supplied by  
the application and/or RFC 3484 address selection mechanisms. When  
this action times out, the second shim looks up additional addresses  
(see below) and tries all source/dest combinations until something  
works. At that point the whole thing is handed back to the calling  
application and the second shim gets out of the way.

Finding additional addresses is a challenge of its own, but a good  
start would be o look up the destination address supplied by the  
application in the DNS, and then look up all AAAA records for the  
resulting name. Whether these addresses are all present on the same  
host or they are for different hosts implementing the same service is  
of no importance at this point.

There is the slight caveat that hosts will now connect to a different  
address than they thought they were connecting to. A weak version of  
the second shim would leave the destination address untouched but  
only cycle through the available source addresses if the application  
specifies IN6ADDR_ANY (yes, yes, I know, this doesn't exist as such).  
In practice we'll probably want some management hooks that allow the  
administrator to specify whcih application/protocols get which  
treatment.

Thoughts?

Delivery-date: Wed, 12 Oct 2005 09:30:51 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 11:29:52 +0200
To: marcelo bagnulo braun <[email-masked]>

On 12-okt-2005, at 11:00, marcelo bagnulo braun wrote:

>> Considering all of this, I think adding a bit and a single insert  
>> shim header / don't insert shim header decision into the core spec  
>> and therefore (presumably) all implementations isn't too much to ask.

> Let me see if i understand:
> Do you want that the base spec explicitly adds a bit in the context  
> establishment exchange that means that insert/don't insert shim  
> header and nothing else so that in other document where the  
> mechanisms for suppressing the shim header can use that?,

This sentence isn't all that clear to me...

> or
> Do you want to include both the bit in the establishment exchange  
> and the mechanisms used to suppress the shim header in the core  
> shim spec?

> I mean are we talking about adding a single bit for future  
> extensibility or the bit plus the complete sets of mechanisms in  
> the core spec?

What I want is:

- one bit (or whatever makes sense after we look at the details) that  
a host can use to tell its correspondent that it doesn't want to see  
a shim header in incoming packets for the context in question
- when indicated by the bit and within some constraints (for  
instance, there are no intermediate headers between the IPv6 header  
and the ULP), hosts implementing the spec are REQUIRED to leave out  
the shim header for packets belonging to this context
- advice that hosts SHOULD set the bit such that the shim header is sent

Under which circumstances the shim header can safely be left out so  
hosts can set/clear the bit can then be explored in a separate document.

Delivery-date: Wed, 12 Oct 2005 09:01:07 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 11:00:15 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/10/2005, a las 10:34, Iljitsch van Beijnum escribi=F3:

big cut...

> Considering all of this, I think adding a bit and a single insert shim=20=

> header / don't insert shim header decision into the core spec and=20
> therefore (presumably) all implementations isn't too much to ask.
>

Let me see if i understand:
Do you want that the base spec explicitly adds a bit in the context=20
establishment exchange that means that insert/don't insert shim header=20=

and nothing else so that in other document where the mechanisms for=20
suppressing the shim header can use that?, or
Do you want to include both the bit in the establishment exchange and=20
the mechanisms used to suppress the shim header in the core shim spec?

I mean are we talking about adding a single bit for future=20
extensibility or the bit plus the complete sets of mechanisms in the=20
core spec?

Regards, marcelo

> Iljitsch
>

Delivery-date: Wed, 12 Oct 2005 08:35:49 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: shim header in every shimmed packet
Date: Wed, 12 Oct 2005 10:34:42 +0200

We had a very productive interim meeting in Amsterdam this weekend.  
But maybe it was even a bit _too_ productive... I have some other  
stuff to say but let me get the main thing out of the way in a  
message of its own.

If you read Erik's proto-00 draft you'll find a mechanism that uses  
the flow label and the next header / protocol field to indicate that  
the shim is active, demux the context (we seem to have settled on  
this word for "shim session") and find where in the protocol chain  
the virtual shim header is located. Although I believe that this use  
of the flow label isn't inherently incompatible with the way it's  
currently defined, this mechanism does have the potential to get  
rather complex when all corner cases are considered. So it makes  
sense to look for something simpler.

And of course, it doesn't get any simpler than simply putting in an  
explicit shim6 header with the context tag in every shimmed packet.  
This is what's on the table now.

I think a shim header is the right choice in certain cases. For  
instance, when there is a protocol chain, having the shim header  
somehwere in there not only serves to make demultiplexing possible,  
but it also explicitly indicates the order of the processing, so  
there can be no confusion. Or when a host uses several ULIDs with the  
same set of locators.

However, I think it's a bad idea to mandate a shim header in all  
cases. When a receiver knows it can rewrite locators into the right  
ULIDs without a shim header being present, it should be possible to  
suppress the header. One way this could happen is when a host has  
multiple ULIDs, but the locator sets for these ULIDs don't overlap,  
such as when ULID A1 has B1 as a locator, and ULID B2 has A2 as a  
locator, then there is never any ambiguity whether an incoming packet  
should be rewritten or not. If there are no issues with header  
ordering (like in the very common case when the IPv6 header is  
immediately followed by a TCP or UDP header) and the source locator +  
destination ULID identify the context, the source address can also be  
rewritten.

So in these cases it makes sense to suppress the shim header. Now  
obviously it may be tricky to determine exactly when the receiver  
will or won't need the shim header, but the good part is that we  
don't have to figure that out now. What I'm arguing for is a  
capability that allows a receiver to let the sender know it doesn't  
need the shim header for a certain context (when there are no  
extension headers). So the only thing we need is specify a capability  
bit in the initial shim exchange that signals this, and require that  
implementatiosn suppress the shim header when the bit indicates this  
is desired.

In the interim meeting, it was argued that something like this should  
be an experimental extension to the shim. I believe that's not good  
enough: it needs to be a mandatory part of the base spec in order to  
be useful. This is why: if it's an extension, this means additional  
work to implement it. With the complexity of an IP stack and the  
upgrade cycles in the most widely used operating systems being the  
way they are, this means it takes a VERY long time to implement new  
capabilities. And since both ends need to implement this, the chances  
of being able to use such an extension within a reasonable timeframe  
are very low. As such, implementers will very likely put this at the  
bottom of their list. Also, in the mean time firewall makers will get  
used to the shim header being there, and things may break if it  
suddenly goes away. So I'm 95% sure that if shim header suppression  
isn't in the core spec, it will never fly.

The question is of course whether saving 8 bytes on shimmed packets  
is worth the trouble relative to the added complexity of having  
packets with or without the header. It looks that to a large degree,  
this is a matter of personal taste. We're essentially increasing  
overhead on IPv6 by at least 1% (7.7% to 8.7%  for two 1500 byte TCP  
packets + an ACK). But we're seeing more protocols that use small  
packets these days, where the increase in overhead is much higher.  
For instance, VoIP with 20 ms samples compressed to 32 kbps with 20  
bytes RTP overhead means 80 bytes data with 60 bytes (75%) overhead.  
Adding 8 bytes increases the overhead by 10% to 85% and makes the  
packet 5.7% larger.

This essentially means we're taking between 1 and 5.7 % of peoples  
bandwidth away (when the shim is in effect). For anything other than  
bandwidth something like this would be inconceivable. I think it's  
the wrong thing to do for bandwidth too, as long as we can avoid it.

Practically, it's already difficult to sell people on increasing the  
overhead for every IP packet by 20 bytes when moving to IPv6. Another  
8 bytes isn't going to help here if we want people to use shim  
multihoming rather than existing BGP style multihoming. The argument  
is that the overhead would only be present when there is a failure,  
but I don't believe it will play out that way in practice: people  
will want to use the shim even when there is no outage for traffic  
engineering purposes.

Considering all of this, I think adding a bit and a single insert  
shim header / don't insert shim header decision into the core spec  
and therefore (presumably) all implementations isn't too much to ask.

Iljitsch

Delivery-date: Tue, 11 Oct 2005 12:19:08 +0000
Date: Tue, 11 Oct 2005 22:17:56 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: Minutes of the Interim SHIM6 WG meeting

At 06:14 PM 11/10/2005, Geoff Huston wrote:
>We know a number of folk are keen to see these minutes, so here's the initial announcement
>
>The minutes of the interim meeting, in pdf format, are at http://www.potaroo.net/shim6/Shim6wg-Interim-Meeting-Minutes.pdf
>
>We'll convert these minutes to html and plain text, and also upload the presentations used at the meeting, in the coming hours, and post a followup note and the minutes in plain text once we've got all that done.
>
>Thanks to those who were able to attend,
>
>regards,
>
>    Kurtis & Geoff

The presentation packs used at the SHIM6 interim WG meeting, and pdf and html markup versions of the minutes are now available at http://www.potaroo.net/shim6

The text version of the minutes is appended to this note.

thanks,

   Geoff

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

                      SHIM6 Interim Working Group Meeting

   Hotel Krasnapolsky, Amsterdam, The Netherlands
   8th - 9th October 2005

   The meeting logistics were generously supported by the RIPE NCC, and
   the SHIM6 co-chairs thank the RIPE NCC for their support.

   In accordance with an announcement to the SHIM6 Working Group Mailing
   List, an interim meeting of the SHIM6 Working Group was held at the
   Hotel Krasnapolsky on the 8th and 9th October, 2005.

Agenda

   The agenda for the meeting was as follows:

    1. Review of current status
    2. Presentation by lead authors on working documents:
        Protocol
            Crypto Locators
            Triggers
            Applicability
    3. Issue identification
        Potential areas:
        locator pairing discovery
            locator pairing state maintenance / cache management
            upper level protocol API / signalling
            mobility implications
            packet header format / content
            shim equivalence state behaviour
    4. Functional decomposition
    5. Next steps (deliverables for Vancouver)
    6. AOB

  Participants

   Jari Akko
       Marcelo Bagnulo
       Pierre Baume
       Iljitsch van Beijnum
       Spencer Dawkins
       Geoff Huston
       Kurtis Lindqvist
       Pekka Nikander
       Ronald van der Pol

  Minute Takers

       Illitsch van Beijnum, Spencer Dawkins and Geoff Huston took notes
       of the meeting. The minutes were assembled by Geoff Huston

1. Review of Current Status

    Protocol Specification
       [1]draft-ietf-shim6-proto-00 

       This is intended to be the core specification document for SHIM6.
       draft-ietf- shim6-l3shim-00.txt will not be further revised, and
       the introductory text will be moved to the shim6 architecture
       document. Section 18 (Design Alternatives) of the -00 protocol
       draft will be placed into an appendix to the document. It is
       undecided at this point whether to keep this appendix in final
       version of the WG protocol specification document, or whether to
       publish the appendix as a separate informational document at the
       same time as the protocol specification document. The l3shim-00
       document is effectively replaced by this document.
       The lead author of this document, Erik Nordmark, has requested
       some assistance with the message diagrams and associated protocol
       interaction descriptions.

  Functional Decomposition
  [2]draft-ietf- shim6-functional-dec-00

       The questions relating to this document were relating to the
       specific purpose of maintaining this as a standalone document, and
       whether parts of this should be folded into the protocol
       specification and architecture document. The current version of
       the document concentrates of consideration of various design
       alternatives. At this stage it is proposed that the documentation
       of design alternatives and specific design decisions taken within
       the SHIM6 specification shall be included in the design
       alternatives appendix of the protocol specification document, and
       material related to the architectural description be folded into
       the architecture draft.

  Hash Based Addresses (HBA)
  [3]draft-ietf-shim6-hba-00

       This document is ready to WG Last Call, and is used by the
       protocol specification (which is based on HBA). The HBA draft
       describes how the hash algorithm works, and it is noted that we
       can WG Last Call the current draft and then bundle it with the
       rest of SHIM6 output for the IESG review and IETF Last Call. It
       was proposed to consult the Ads regarding cross-area review of
       this document needs, specifically including security community
       review.

Action: Chairs to perform a Working Group Last Call on the HBA Draft

Action: Chairs to refer the document to the ADs for cross-area review,
   with specific request for security review.
   
   Ingress Filtering
       [4]draft-huitema-shim6- ingress-filtering-00

   It was commented that ingress filtering is operational practice
   (BCP), not a particular protocol standard.

   [5]RFC2827 Network Ingress Filtering: Defeating Denial of Service
       Attacks which employ IP Source Address Spoofing

       There are many ways that the issue of potential ingress filter-based
       packet drop based on a source address filter match at the site
       boundary interface could be addressed. It is also noted that the
       issue here is not entirely limited to packet discard through ingress
       filter, but that selection of a specific source address by the host
       may be used as a mechanism for a host to select a specific site
       egress path where there are multiple egress paths offering
       equivalent or overlapping destination reachability. The question of
       whether source address selection can be used for egress path
       selection is an open one, and the mechanisms proposed in the draft
       are not in common use at present.

       The question considered was whether the draft contained material
       that was considered critical for the protocol draft. It was noted
       that the decision to use source address selection as the signalling
       mechanism between the host and the sites packet forwarding framework
       is not one that the WG has made. If it's a precondition for SHIM6
       that source addresses matter, the WG needs to sanity-check this
       decision really soon, because the impact on routing and forwarding
       systems within sites is very significant. It is also noted that the
       sites internal source-address forwarding mechanism is not required
       in all cases (if you have full BGP at a single site edge router, for
       example). Multihoming may not be comprehensive in terms of traffic
       surviveability, and, for example active SHIM6 traffic may failover
       but default-routed non- SHIM6 traffic would not. If detection and
       repair aren't unidirectional, the "other end" gets hints that things
       need to change, but the new source address doesn't "steer" the other
       end traffic to take a particular incoming path. While it was
       considered that these concerns are relevant to SHIM6, they can be
       considered to be orthogonal to the protocol specification.

       The question of adoption of this draft as a WG document was
       considered, It was noted that there are a lot of good ideas
       discussed in this draft, but its unsure that this document needs to
       be part of the SHIM6 document collection. The central SHIM6 concern
       is that of hosts selecting among site exit paths, rather than the
       general ingress filtering problem. One conventional approach would
       be to consider and possibly document the requirements first, and
       then solicit proposals that meet the requirements. It was also noted
       that the SHIM6 approach is to propose a minimal set of changes here.
       It was felt that more information would assist the WG in considering
       whether to adopt this document as a WG document.

Action: Marcelo Bagnulo to draft a matrix of scenarios and solutions
   relating to this ingress filtering and site exit path selection,
   intended for presentation at Vancouver.
   
   Address Selection
       [6]draft- bagnulo-shim6-addr-selection-00

       This draft notes shortcomings in RFC3484 in terms of trying all
       source/destination combinations, not just all destinations, in a
       multi- addressed local context, irrespective of local SHIM6
       capability. The context in SHIM6 is the proposed operation of
       initial contact, where the current specification refers to RFC3484.
       It was considered that if the major difference between the current
       version of RFC3484 and this draft is the consideration of source
       address ordering, as distinct from just source address selection,
       then this would be a relatively small textual amendment to RFC3484.
       Implementing this change may be challenging, however. It was noted
       that this proposed change to RFC3484 would address the SHIM6 charter
       item that refers to Solutions to establish new communications after
       an outage has occurred that do not require shim support from the
       non-multihomed end of the communication. The discussion in this
       draft will be used to support the case for proposing changes to
       RFC3484, but it was considered that as this was the output of the
       IPv6 WG, further changes to this specification should be considered
       by the IPv6 WG. Determination of this question was considered to be
       a decision for the ADs.

Design Note: The specification for initial contact will use RFC3484,
   as modified by this draft in terms of source address ordering.

Action: Marcelo Bagnulo to draft a note outlining a set of specific
   text changes to RFC 3484 to support the approach proposed in the
   address selection draft

Action: Chairs to pass this note and the address selection draft to
   the ADs, with the recommendation that changes to RFC3484 be considered
   by a WG in the Internet Area.

   Application Referral
       [7]draft-ietf-shim6-app- refer-00

       It was noted that this draft is not on the critical part in terms
       of completing the initial core protocol specification. It was
       noted that there a large number of issues with application
       referrals with Site-Local addresses, and this has the potential
       for similar characteristics. The draft notes that if a FQDN is not
       being used as the referral object, the options include the passing
       of a ULID as the referral object or passing the entire locator set
       as the referral object. The locator set object could be useful to
       assist in terms of initial contact, but this has some API
       implications for upper level protocols. The intent with the
       locator set was to use an object that it is not intended that
       applications understand the semantics of these locator sets.

  Applicability
  [8]draft-ietf-shim6- applicability-00

       Applicability document is currently a placeholder document, which
       will be revised once the core protocol specification has been
       stabilised.

  Failure Detection and Reachability Exploration
  [9]draft-ietf- shim6-failure-detection-00 
  [10]draft-ietf-shim6-reach-detect-00

       As the topics of failure and reachability are very closely related
       the immediate steps are proposed to be merging these two drafts
       into a single document that describes the state conditions where a
       failure condition will be triggered, and also describes the
       exploration procedure that attempts to recover connectivity though
       a structured search of the locator pair space to discover locator
       pairs that offer host-to-host reachability. The decision whether
       to further fold this combined failure detection and reachability
       exploration specification into the core SHIM6 protocol document
       will be considered at the SHIM6 WG meeting at IETF-64 (November
       2005).
       It was noted that there is reference to IPv4 and RFC1918/NAT
       conditions in the current document, and it was proposed that this
       text be removed from the SHIM6 documents on the basis that the WG
       has no charter beyond specification of IPv6 mechanisms. However it
       was noted that the HIP WG and HIP RG may find the extensions of
       this approach in IPv4 and RFC1918/NAT contexts a useful approach
       useful in terms of avoiding reinvention in this area.

  L3-SHIM
  [11]draft-ietf-shim6-l3shim-00

       As this document is effectively replaced by the shim6-proto
       document, it will not be further revised by the WG.

  Architecture
  [12]draft-ietf-shim6-arch-00 

       As discussed in the previous WG meeting in August 2005, this
       document will be revised once the core specification is
       stabilized.

  Upper level Protocol API

       A document describing the forms of interaction with upper layer
       protocols has yet to be drafted. Pekka Nikander has sent some
       thoughts to the mailing list on this topic, but these have not
       been submitted as a draft as yet. A January / February 2006
       submission time is anticipated. The perspective proposed is to
       consider this from a SHIM6-centric perspective (what signalling
       from the upper protocol layers would SHIM6 consider a helpful
       indication?). The larger topic of locator pair selection as an
       indirect method of forms of host-based traffic engineering and
       performance / service quality selection would be held over for now
       and the initial API effort would concentrate on an API that
       supports signalling to a core SHIM6 specification. The WG
       considered that when a richer API was being considered by SHIM6
       WG, then some assistance from TSV would be of a significant
       benefit to the consideration of this topic.

2. Presentations by Lead Authors on Working Documents
3. Issue Identification
4. Functional Decomposition

     These three items were considered jointly by the WG.

     Protocol Specification
     Erik Nordmark

     * The specification has made a number of arbitrary design choices
       based on alternatives described in the prior l3shim document in
       order to make progress.
     * The approach of placing the context tag in flow label field was
       considered - the MTU problem isn't really a big problem, so why
       are we hacking in the flow label to solve it?
     * Do uncoordinated state removal with error message when peer
       removed/lost state is detected.
     * Use of Flow Label and modified Protocol numbers as an encoded
       SHIM6 header in the IPv6 packet header. New protocol number for
       control protocol (similar to ICMP), overloading of port number
       semantics for TCP, UDP, etc. Need to tell receiver "this packet
       needs special handling". Other protocols are also reusing flow
       label (NSIS, etc.).
     * Related topic - ordering of processing for multiple items in
       headers.
     * Is this a candidate for optimization (after we get the base
       protocol working)? If most conversations don't fail, we usually
       don't need this optimization anyway.
     * We're concerned about possible "flow label collisions" between
       protocol mechanisms that are trying to reuse the same header
       field.
     * We're concerned about bouncing back and forth between IP code and
       TCP code in some implementations. Why are we trying to avoid using
       a small number (8) of packet header bytes? Upper layer protocols
       already have to deal with changes in MTU size due to routing
       changes, etc.
     * The architectural intent for IPv6 is to do use a specific header
       for such signalling between endpoints. Can we optimize later?
       Would need to be a stronger case to optimize later. If we think
       people are going to use SHIM6 for something like traffic
       engineering, we'll do this more often than just in failure modes.
       Are we still using MPLS for traffic engineering, too? If so, we
       would have an end-to-end signaling mechanism to negotiate stuff
       like this anyway. Draft doesn't consider exhaustion of flow
       labels, using multiple flow labels, etc. which would add a lot
       more complexity. Could have an extension protocol that says "these
       upper-layer identifiers are being SHIM6ed", so packets don't have
       to carry any information at all - there's a whole capability
       negotiation mechanism that would be useful. Indications of
       "willingness to SHIM6" are unidirectional, so don't have to
       coordinate between endpoints. Can we start out with an explicit
       SHIM6 header and return to this later? Is this research now
       anyway? We could use the approach of an experimental extension
       protocol to deal with a number of things that we don't understand
       now.
     * Sense of the room is to use the explicit headers in the base
       protocol specification and go on. This also allows us to use a
       larger/better context identifier (we had picked 20 bits because it
       fits in the flow label, in the previous draft). It also means that
       SHIM6 control packets and data packets will tend to pass or be
       blocked by firewalls together (instead of passing control protocol
       packets and then failing data packets).

Design Note: Use an 8 byte IP SHIM6 header in the base protocol
   specification for packets that require specific SHIM6 processing by
   the receiver, and allow optimizations on this, including that of a
   zero-length header, to be an experimental protocol extension.

     * Do we need a checksum in the control packets? Certainly not in
       every SHIM6 packet, but checksums are more valuable in the control
       packets.

Design Note: Use a header checksum on the SHIM6 control packets but no
   in the SHIM6 packet header.

     * How "unique" are context tags? We are thinking about context tags
       as a way of resisting injection attacks, so longer is more
       attractive. We will end up with a 32-bit context field and about
       15 bits as "reserved".

Design Note: Use a 32 bit context field with no checksum, and 15
   reserved bits and a 1 bit flag to indicate control / payload. Note
   potential DOS risks

     * Failure in initial contact? The direction here is to refer to an
       updated 3484 (source address set), and may ask that a
       bidirectional ULP (such as TCP) retry multiple initial SYNs with
       various source/destination locators. Is this sufficient? One other
       possibility - "is this locator already part of another locator set
       that has been previously established?" And how do we cache this?
       Is this an API construct (ULP sends down the locator set and gets
       back a ULID from SHIM6 if a SHIM6 context already exists for this
       locator set)? Building on existing SHIM6 context state is similar
       to TCP sharing congestion information across TCP connections, so
       we can anticipate that SHIM6 API support at initial contact time
       would get used by upper layers.
     * What about exchanging SHIM6 information that allows SHIM6 peers to
       exchange ULIDs before initial SHIM6 context is established?

Design Note: For initial contact use RFC3484 (bis)

Design Note: Possible experimental ULP API extensions to initial
   contact:
    1. Enhanced Contact would result in searching existing SHIM state
       based on initial locator set. (This may return a ULID pair that
       was not in the ULPs locator set is this a problem?)
    2. SHIM6 Contact would perform the contact step above, and where
       there was no SHIM6 context, then trigger SHIM6 state
       initialization and returned to the ULP the ULID pair with SHIM6
       state set up
    3. Ordered Locator Set (getaddr_pair_set_info()) returns an RFC3484
       ordering of locators based on local SHIM6 state information. This
       could be used to construct a connect_by_name() approach

     * We're not using ICMP messaging to indicate loss of state because
       of our concerns about ICMP filtering in today's Internet. If we
       use the same protocol for messaging and error notification, that
       protocol either makes it through firewalls or it doesn't, instead
       of failing during error notification, for instance.
     * Can a SHIM6 peer decline SOME of the locators offered by another
       SHIM6 peer? HIP experience was that a general update/ack protocol
       was useful to update locators, SPIs, etc. MOBIKE also has a
       similar underlying protocol as well. May include locators and
       preferences between locators.
     * How many offers/counteroffers do we need to support?

Design Note: For SHIM6 control messages use a unidirectional
   acknowledged information transfer UPDATE and ACK message transaction
   as the base protocol, and then specify control messages in terms of
   control message types and attributes.

Open Issue: Do we need a simply NOTIFY (un ACKed UPDATE) message type
   as well?

   Placeholders in the specification:

     * CUD/FBD? Locator pair test/reply (Eric suggests that we drop
       this), and context explore messages.
     * Locator pair test/reply (need to be independent of ULIDs, and note
       that there may be multiple ULID pairs associated with the same
       host pair)
     * Reachability exploration for a working locator pair
     * What are privacy requirements for locator lists? Also integrity -
       this protocol is currently "in the clear".
     * "Forking the context state" for preferring different locator pairs
       for different ULP communications? How close is this to policy? Is
       this unidirectional or bidirectional? How much information does
       SHIM6 get from the ULPs that would go into this decision? This is
       similar to MONAMI6 work previously done. Preference for viewing
       this as a unidirectional rather than bidirectional search,
       although in a destination-based hop-by-hop forwarding environment
       without source-address routing considerations a pair of source-
       address locators in each direction is functionally equivalent to a
       single bidirectional pair.

Design Note: Locator pairs are considered as unidirectional locator
   pairs, and there is no assumption that these must map into a
   bi-directional pair.

     * Locator list option has all locators, but HBA parameter set has
       prefixes that reflect all locators, too. Is this needed in both
       places?
     * Do we need a generation/version number for the locator list? This
       isn't the same as transport sequence numbers that are used for
       reliability. Could we recover more rapidly if we know what version
       number we are current with? But we're sending entire sets now, not
       sending deltas. Don't want to list entire IPv6 address locators in
       order to change preferences? But it is simpler to send the
       addresses than to send the addresses and then send preferences by
       index.

Design Note: Do not use locator ordering and index references in SHIM6
   control messages in the initial base spec

     * Detecting loss of context doesn't work while the ULID pair works
       as the locator pair, so the peer may have garbage-collected the
       context and you didn't notice until there is a failure.
     * What do you do if you receive contexts that you don't understand?
       Send an error, if it's a control packet, or silently discard it,
       if it's a data packet? Eventually you notice because of
       reachability detection anyway - do we need to notice more quickly
       than that?

Design Note: We need to indicate which LLU locators should be verified
   with HBA, CGA, or some future mechanism.

     * 32-bit contexts could be DOSed - do we need more bits?
     * Which SHIM6 control messages need sequence numbers?
     * Remaining Design Alternatives...
     * Need to make a decision on state cleanup, choosing uncoordinated
       cleanup.

  Sharing base packet format with HIP for SHIM6 Control messages

   Pekka Nikander

     * One perspective on HIP and SHIM6 is that SHIM6 is a semantic
       subset of the HIP approach (Assertion - SHIM6 is a subset of the
       problems HIP is trying to solve)
     * This is not thinking about "same state machine and same
       semantics".
     * But a common packet format would help with areas of potential
       experimental protocol extension
     * Current HIP packet layout is pretty different from SHIM6 packet
       layout, but (ignoring HITs) the contents are pretty similar.
     * Option format - is 256 bytes enough for CGA signatures? If not, we
       have 16-bit length, so having 16-bit type makes more sense, and we
       may end up with something that is a close approximation of the HIP
       parameter format in any case
     * Not proposing a single shared parameter space until we know a lot
       more about HIP than we know today.
     * Why did we use 8-bit options, and would 16-bit options be a
       problem?
     * Our biggest expressed concern was a perception problem that SHIM6
       is
     * ntending to generate a proposed standard, while HIP is
       experimental. That would imply a position that any resemblance to
       the current HIP packet format is entirely coincidental, but useful
       in various experimental contexts.

Design Note: The SHIM6 packet formats have been updated to
   * have a 32 bit context tag
   * checksum in same place as in the hip header
   * a 1/0 bit to distinguish the payload vs. control messages
   * have a 16 bit option type and length

   For the most control messages this results in 7+16 reserved bits. Most
   of the fields are 32 bit so they can't fit in here.
   * Adopted HIP parameter format for options; HIP parameter format
     defines length in bytes but guarantees 64-bit alignment.

[Meeting adjourned for dinner, restarted on Sunday morning.]

   Protocol Specification Placeholders (review)

     * Locator pair test and response

Design Note: Proposed to drop specific mechanism for locator test and
   response

     * Reachability exploration: what locator pairs are working after a
       failure? (actually find me the first locator pair that works)
       refer to the failure and reachability work.
     * Locator list option has all locators, but HBA parameter set has
       prefixes that reflect all locators, too. Is this needed in both
       places?: We think it's OK to duplicate locators and prefixes in
       our messages.

Design Note: Allow both locator set enumeration and HBA parameter set
   in an UPDATE message

     * What are privacy requirements for locator lists? Also integrity -
       this protocol is currently "in the clear".

Design Note: Place this topic into the larger item of possible areas
   of protocol extension, and note in the Security Considerations of the
   protocol specification that we have considered this and are advising
   that this falls into an area of potential protocol extension activity.

Action: Pekka Nikander and Marcelo Bagnulo to work in a draft of
   Guidelines for potential protocol extensions for SHIM6, including (but
   not limited to)

     * flow label use / header compression,
     * privacy,
     * hash chains and security,
     * initial contactless SHIM6 context establishment ,
     * API interaction for initial contactless SHIM6 context
       establishment
     * Locator pair selection based on signalled preferences
     * Return path locator preference signalling

     * Forking of context state - is this unidirectional or
       bidirectional? Strong preference voiced for a unidirectional
       forked state. Two goals here - traffic engineering for a site, and
       different traffic types between the same two hosts. Traffic
       engineering seems closer to what we know about at IP level -
       "different traffic" may be a lot more open-ended. Mobile IP and
       HIP have similar issues. One proposal advanced was to schedule a
       joint working session in IETF-65with TSV and RTG? We won't know
       enough to meet on this subject in IETF-64 in November 2005. Can we
       require that this be done at ULID selection time? SCTP has similar
       problems (but SCTP is closer to the application than SHIM6). SHIM6
       is providing a hook for something finer than host-to-host
       granularity, without trying to solve all conceivable problems.
       Bidirectional context state forking is seen as a ULP signalled
       outcome.

Design Note: View forking as a unidirectional context state fork
   (based on a ULP signal) that assumes that the forked context state may
   then use a different outgoing locator pair.

     * Run with a version number for a locator set?
     * Detecting context problems while the original ULID pair works as a
       locator pair? Need to detect the problem before a failure happens.
       Ping periodically? If we send R1 as a context error message, we're
       already starting to re-establish the context state. Why would any
       host that was SHIMming decide to stop doing so? We need to make
       sure that we don't require continuing packet exchanges without
       advancing to context established state. The R1 values are slightly
       different (we don't have an initiator context tag from a request,
       we are using the context tag that we believe the peer thinks we
       have). We think that trying to return to non-SHIMmed operation
       when a host garbage-collects context is probably a mistake - we'll
       just "die".
     * What happens if the A end garbage-collect its state and later
       reuses the same context number with the same B end host? Should
       the B end have the new context replace old B end context state and
       just go on? There is a race condition if the remote end is trying
       to reestablish the context that has already been locally
       garbage-collected, and the remote end is trying to send using the
       old context. There's a concern with forged packets that try to
       reestablish the context resulting in a DOS. Can we include in the
       context tag generation algorithm some bits from the sender of the
       packet, as well as the receiver of the packet who chooses (most
       of) the context tag value, so the context tag has bits from both
       ends and we can tell context 3.1 from context 3.2? Context numbers
       that are pseudo-random would help, but we can't prevent collisions
       completely. If applications can provide hints to SHIM6 that the
       application is still alive ("so don't garbage-collect"), that
       would help. A usage counter can tell you if garbage collection of
       the context state at this point in time would be a bad idea (as
       its still active), but not if it's a good idea. If we can get
       unwedged, that's the important thing - being wedged less often is
       an optimization.
     * What do you do if you receive contexts that you don't understand?
       Send an error, if it's a control packet, or silently discard it,
       if it's a data packet? Eventually you notice because of
       reachability detection anyway - do we need to notice more quickly
       than that?

Design Note: On receipt of a SHIM6 payload packet where there is no
   current SHIM6 context at the receiver, the receiver is to respond with
   an R1* packet in order to re-establish SHIM6 context. The R1* packet
   differs from the R1 packet in that an R1 packet echoes the I1 fields,
   while this R1* offers state back to the sender. Either way the next
   control packet is an I2 in response. The senders previous context
   state is to be flushed in receipt of the R2 packet following the R1*,
   I2 exchange

Action Item: Marcelo Bagnulo to review this and consider possible
   issues with this form of SHIM6 protocol response.

Action Item: Erik Nordmark to document the alternative SHIM6 context
   setup where each side offers one half of the constext value, so that
   unnecessary context destruction is avoided for WG consideration.

     * Are four packets really necessary in the SHIM6 context
       establishment? IKEv2 doesn't require cookie to be present in all
       packets, only when we suspect we're under attack. But this could
       be an experimental extension. SYN flooding is still incredibly
       difficult to deal with operationally (because each packet is just
       a normal packet). We are in better shape than IKEv2 because
       packets are still flowing "normally" while we are setting up SHIM6
       context. This could be a potential experimental protocol
       extension.

Action Item: Marcelo Bagnulo to document a shorter context
   establishment protocol exchange based on the IKEv2 approach (as a
   potential experimental protocol extension).

     * Which SHIM6 control messages need sequence numbers?

Design Note: SHIM6 control message sequence numbers are not needed
   here.
   Reachability and Failure Detection
       Jari Akko
       Iljitcsh van Beijnum

   Failure

     * "Primary" isn't quite the right term (it's mostly "the locator we
       started with")
     * We won't reinvent DHCP, and we will believe what ND tells us.
     * SHIM6 is only expected to be used in failover scenarios. Shim6
       only works as a failover
       i.e. different hosts may have different locator sets for the same
       remote host
       i.e. a pair of communicating hosts can have multiple contexts with
       independent locator sets.
       Right now the hint is the ULID pair differentiation
     * Different contexts do not necessarily imply different ULID pairs
     * FBD is chosen for simplicity

Design Note: Use FBD as the reachability algorithm.

     * Sender chooses outgoing address pair (independently of the choices
       made by the remote host)
     * Failure Detection:
         1. If you receive anything when you are sending packets, assume
            that all is well.
         2. If you aren't sending or receiving packets, assume that all
            is well.
         3. If you are receiving packets and don't need to send payload
            packets, send some form of keepalive.
         4. If you are sending payload packets and aren't receiving
            anything (payload or keepalives), assume that something is
            broken after time interval T.
     * We need a time base in order to send keepalives, and an associated
       timebase for non reception of in-coming packets within the SHIM6
       context.
     * Peers need to have a shared understanding of how long this
       timeslot is. We need to understand the relationship between
       timeslots and RTTs (and need to keep from reinventing TCP within
       SHIM6 with focus on RTTs). Would prefer not to initiate an
       exhaustive locator exploration just because SHIM6 is confused
       about the peer's timeslot choice. We need to think about how
       aggressive we want to be about failure detection. Exploring this
       futher, it was observed that 10 seconds is fast as compared to
       BGP4 current practice (1.5-3 minutes). There is a startup
       transient that is also critical here. Should the initial
       specification used a statically defined time interval, or does
       SHIM6 adaptively learn? Is there a difference between symmetric
       idle and assymetric idle? We have some concerns about interaction
       with higher-level protocols that may also be trying to do recovery
       asynchronously (and applications that may differ in the goal for
       failover). Should this detection and recovery mechanism be faster
       than a TCP ULP? Should the routing state timers in OSPF and BGP be
       a factor here. TCP timeout is an upper limit. Within that
       constraint, we have three choices for the timeout: slower than BGP
       (so we give BGP the chance to repair the failure: > 90 (RFC) or
       180 (Cisco) seconds), between BGP and OSPF (give OSPF the chance
       to repair: > 40 < 90 or 180 seconds) or faster than OSPF: < 40
       seconds.

Design Note: Use a statically specified in the initial protocol
   specification of (10) seconds.

   The idle keepalive trigger is statically specified to be 3 seconds.
       This value may be negotiated at SHIM6 context startup as an
       experimental protocol extension
       This value may be dynamically altered during the SHIM6 context as
       an experimental extension

     * The meeting noted other candidate timers, including setting the
       value between 24 and 36 seconds.

   Reachability Exploration
     * Exploration may be a uni-directional discovery, but a
       bi-directional shared computation
     * Exploration uses an attempt to synchronize on a state, using a
       format where each sent probe carries information relating to all
       received probes so far.
     * Exploration also makes use of timers in terms of assumptions of
       failed probes
     * In exploration for a viable locator pair it is noted that only one
       end may know there's a problem, and knowing when to STOP exploring
       is really hard.
     * Note FBD only detects failures in the incoming path.
     * Consideration of the use of a quick check as the initial response
       before launching into a full exploration.
     * Must SHIM6 recognize a keepalive as a keepalive? This is not
       strictly required in FBD, as its SHIM6 packets rather than
       specific packet content or type that count here, but we have to be
       able to recognize keepalives as keepalives to avoid sending
       keepalives in response to keepalives.
     * Also note that it's an issue to determine when to STOP sending
       keepalives when neither peer has traffic to send.
     * It is also a relevant consideration of how firewalls react to
       keepalives (probably react badly to IP packets with no payload
       whatsoever (header only), probably use SHIM header with keepalive
       option.
     * The concept of a host-id was considered as a way of identifying a
       host across multiple ULIDs. Need an algorithm to make sure all
       hosts choose a unique host ID (same theory as router IDs). How do
       we change host IDs if the chosen locator was deprecated?
       Alternative is to work with sets of locators (instead of host IDs)
       - "this is the set of locators I think you have".
     * How dynamic are locators sets (with CGA, etc.)? ULIDs don't change
       as long as there is any session active.
     * A common probe data structure is proposed to be reused in several
       packet layouts.
     * Quick check request/reply mechanism (we think this path will work,
       we're just making sure), plus full exploration with context
       reference. Some concerns about DOSability of including context
       information as part of reachability (reflection attacks, etc.).
       Including "last few" probes in each direction (allows you to
       detect relatively slow locator paths). Does this extend into
       sending complete metrics for all locators on each probe? Could
       send last 3 successful probes, last 3 failed probes, etc.
       Balancing amount of hints on path selection with amount of
       information sent. Unsuccessful probe information could be really
       useful ("move these locators to the end of the list"). 30-40
       second-old information is ancient history.
     * Start full exploration when you timeout on quick check.
       "Exponential backoff" - sending probes to more locators over
       greater intervals. Some discussion about choosing "best" or "first
       as good as previous" paths based on RTT vs simply choosing a
       working path - concerns about minimizing RTT versus other QoS
       values (jitter, etc.). Moving beyond "works" as a discriminator
       should be an experimental protocol extension. Moving "back" to the
       original locator pair should be an experimental protocol
       extension. The subtext is "getting off my GPRS backup ASAP", and
       that's really hard to generalize.
     * Propose to use this probe structure in all SHIM6 packets (would
       give us better RTT measurements)?
     * When should exploration stop? When you have any candidate locator
       pair? Or continue to see if there is a better candidate pair?

Design Note: Continued exploration to see if a better locator pair is
   available following identification of a viable locator is considered
   to be an experimental protocol extension. The exploration in the base
   protocol specification will terminate once a viable 9reachability
   confirmed) locator pair has been discovered.

   Reachability (v2)

     * Reachability, version 2 (REAP) - using the same messages for four
       complimentary functions (direct reachability, reverse-path
       reachability, checking different return paths, return routability
       checking). Including a mechanism for not having to probe in both
       directions simultaneously.
     * How long do we continue to probe? Keep context state around and
       wait for upper layer apps to "try again". We may wish to remember
       paths that previously failed so we try them LAST during the next
       failure.
     * Some discussion of how close REAP comes to being STUN protocol
       when we have unidirectional path failures... is this ALSO an
       experimental extension?
     * Some discussion of how long we have to deliver SHIM6 baseline
       functionality (time and energy), and how our charter maps to
       "providing IPv4- equivalent multihoming in IPv6".
     * Some discussion of unidirectional path failures - isn't this
       usually due to ingress filtering? Can we assume that we don't have
       to recover from unidirectional path failures in SHIM6? But we have
       to detect this condition, even if we don't recover from it. We
       think we can assemble two unidirectional paths into a single
       bidirectional path, but don't know all the implications. We need
       to be able to steer traffic based on source addresses to
       accomplish this. Should continue exploration until we identify a
       working bidirectional value. RFC 3484bis and SHIM6 setup and
       recovery will all require bidirectional paths - don't SHIM6 setup
       over unidirectional paths (because RFC 3484bis has a working path
       already, no reason to try to improve it in the face of failures).
       Should we allow setting up a SHIM before there is a context? Need
       I1bis that says "send this back using a different locator" to make
       this work. Concern about creating state? but maybe allowing state
       on the INITIATOR is OK, as long as we don't require state on the
       RESPONDER. May have to do M x N scan to find something that works.
       May need "API on steroids" to initiate this process.
     * REAP - Four functions:
         1. Direct reachability the message can get to the receiver
         2. Indirect reachability earlier messages got to the sender
         3. Redirected response request the receiver to use a different
            (specified) locator pair for the response
         4. Perform a return routeability test

       Another way to look at exploration is that of an exploration of a
       matrix of locator pairs, with sender using locator Pair (a,b) and
       the receiver using the locator pair (a,b), and each cell of the
       matrix is itself a 3x3 set of possible information states, whether
       traffic has been sent on the sending locator pair, whether traffic
       has been received on this pair and what the local (sender) end
       thinks it knows about the other (receiver) end.

       Related issues: how many probes before the algorithm can consider
       the locator pair unuseable? How many passes across the full
       exploration space before the algorithm terminates with complete
       failure?

Design Note: Where we are:
     * Initial contact: 3484 (bis) is bidirectional
     * Shim setup is bidirectional based on initial locator set
     * Recovery from failure is potentially unidirectional

Design Note: Questions:
     * Should shim setup allow unidirectional? No point per se unless you
       have shim6 setup WITHOUT context
     * Should 3484 be extended to allow unidirectional? No
     * Should shim6 be allowed to setup without initial established
       context? If yes, should it include unidirectional discovery?
     * Should failure recovery continue to see if there is a
       bidirectional locator pair even though there was already a
       unidirectional path

     * Note that the modified I1 in this case would include a STUN-like
       request to pass a packet back with a different locator pair than
       the received I1 packet

Action: Document the simple cases

Action: Document this concept of shim6 context without initial
   bidirectional initial contact (i.e. shim6 initial context passes into
   an initial walkthrough) and API considerations

Action: Initial reachability detection aim to get a unidirectional
   support version drafted by November. Pekka Nikander and Iljitsch van
   Beijnum to do an individual submission for working group review.

5. Next Steps

     * Produce -01 of the protocol draft immediately following this
       interim WG meeting
     * Perform a WG Last call of the HBA draft
     * Reachability detection aim to get a unidirectional support version
       drafted by Vancouver
     * 3484bis pass documented requirement to ADs to see where it's
       actually reviewed.
     * There may be impacts on the HBA draft if there is an option
       structure added to CGA. We think Marcelo can handle this, before
       IETF-64.
     * Want to make sure everyone agrees that the base protocol extension
       represents a conservative, but workable approach and at this stage
       consider further refinements to be experimental extensions. Check
       with the working group to see if unidirectional support goes in
       the base protocol? (Does the WG agree that STUN-like response
       redirection is a good thing to include in the base protocol? We're
       saying that the API must allow applications to specify ULIDs,
       we're saying that I and R packets must support response
       redirection - maybe this is a reply redirection AND a reply that
       says what the original addresses were.

References

   1. draft-ietf-shim6-proto
   2. draft-ietf-shim6-functional-dec
   3. draft-ietf-shim6-hba
   4. draft-huitema-shim6-ingress-filtering/
   5. rfc2827
   6. draft-bagnulo-shim6-addr-selection
   7. draft-ietf-shim6-app-refer
   8. draft-ietf-shim6-applicability/
   9. http://draft-ietf-shim6-failure-detection.potaroo.net/
  10. http://draft-ietf-shim6-reach-detect.potaroo.net/
  11. http://draft-ietf-shim6-l3shim/
  12. http://draft-ietf-shim6-arch.potaroo.net/

Delivery-date: Tue, 11 Oct 2005 08:14:42 +0000
Date: Tue, 11 Oct 2005 18:14:12 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Minutes of the Interim SHIM6 WG meeting

We know a number of folk are keen to see these minutes, so here's the 
initial announcement

The minutes of the interim meeting, in pdf format, are at 
http://www.potaroo.net/shim6/Shim6wg-Interim-Meeting-Minutes.pdf

We'll convert these minutes to html and plain text, and also upload the 
presentations used at the meeting, in the coming hours, and post a followup 
note and the minutes in plain text once we've got all that done.

Thanks to those who were able to attend,

regards,

     Kurtis & Geoff

Delivery-date: Tue, 11 Oct 2005 08:05:06 +0000
Date: Tue, 11 Oct 2005 10:04:37 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: Mohacsi Janos <[email-masked]>, John Payne <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, David Meyer <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

Cross posting removed - this is a mainstream shim6 comment...

Jason Schiller ([email-masked]) wrote:
...
>>I hope the proposed BOF will make this clearer. I personally
>>think that shim6 will be really cool for ISPs, although as Geoff
>>says it will take a while to deploy and during that time we'll
>>need a PI-like approach.
>>
>>     Brian
> 
> 
> There are many content providers who are avoiding IPv6 as they beleive it
> is not yet ready for "prime time" commerical traffic as it lacks sufficent
> multi-homing capabilities.  Clearly we need a multi-homing solution
> now.  However I am concerned that if we allow PI addresses into the global
> routing table, then we begin down the path of solving the multi-homing 
> problem by de-aggregating.  In 10 years time, there may be many
> de-aggregates in the global routing table.  At that time it will be much
> harder to tighten the belt and get those prefixes out of the global
> routing table.  

Absolutely.

> 
> Do you think that operators of commercial networks will want to switch to
> shim6?

They won't need to. Shim6 deploys in the hosts. An ISP doesn't have
to do a single thing to enable or switch to shim6. Customer sites with
two PA prefixes will just start multihoming. That's the beauty
of it.

A local ISP might decide to facilitate shim6 for the benefit of its customers
(i.e. the ISP plus its subscribers becomes a "site" in shim6 terms). That
ISP would indeed have to do something, but not much - advertise two prefixes
to its customers, who would thereby get 2N addresses where they had N
addresses before. Shim6 would do the rest in the hosts.

[In both cases I've skimmed over exit router selection issues, which
still needs work.]

> Consider the current comfort level with the IPv4 style BGP
> de-aggregate traffic engineering.  Consider that the current approach to
> shim6 is less functional than the current IPv4 style multi-homing. 

I don't think that's true, from the requirements viewpoint
of the end user.

> Consider the the shim6 solution may be very different to operate
> (configuring end hosts instead of Internet facing routers) 

No configuration involved. Just a shim6 capable stack.

> and may
> break current operational boundaries.  

It seems more likely to make them irrelevant, to me.
> 
> Shim6 as a host multi-homing solution lends itself nicely to consumer
> networks all operated by few end users with few hosts, but is more
> problematic to implement it in a large commerical network.

I really don't see that, modulo the exit router selection issue.

> 
> Don't miss read me.  I'm not bashing shim6.  I'm suggesting it needs to be
> as functional as what operators currently have.  
> 
> I'm also suggesting that there is a barrier to change, and if traditional
> IPv4 style multi-homing is allowed to be done in IPv6 then comercial
> networks may never adopt a shim6 solution.

They will have to, when PI scaling starts to break things.
> 
> ARIN is currently considerig PI IPv6 space.  See Policy Proposal
> 2005-1: Provider-independent IPv6 Assignments for End Sites:
> 
> http://www.arin.net/policy/proposals/2005_1.html
> 
> It is my belief that if this policy goes through that commercial sites
> will
> be unlikely adopt a shim6 solution.  

There's a big difference between what major sites with the weight to
get their prefix advertised can do and what small and medium businesses
without such weight can do. I don't doubt that a few thousand major
corporations will end up with PI-like solutions. I know that won't happen
for tens of millions of small and medium businesses. I hope that ARIN
and all the RIRs move very carefully, for that reason.

    Brian

Delivery-date: Tue, 11 Oct 2005 07:46:59 +0000
Date: Tue, 11 Oct 2005 09:45:48 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Paul Jakma <[email-masked]>
CC: John Payne <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, [email-masked], David Meyer <[email-masked]>, [email-masked], [email-masked], Mohacsi Janos <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

Paul Jakma wrote:
> On Mon, 10 Oct 2005, Brian E Carpenter wrote:
> 
>> The point of shim6 is to *avoid* the need for PI-like space for 
>> multihomed sites, so that we don't do to the IPv6 BGP table what 
>> multihoming is doing to the IPv4 BGP table. We need IPv6 to scale 
>> vastly more than IPv4, so this is essential.
> 
> 
> The problem isn't PI addressing, it's advertising tiny prefixes in the 
> routing table. PI addressing *without* global-routing-table visibility 
> *would* obviously scale for routing. We just don't have a way to do this.
> 
>> I hope the proposed BOF will make this clearer. I personally think 
>> that shim6 will be really cool for ISPs, although as Geoff says it 
>> will take a while to deploy and during that time we'll need a PI-like 
>> approach.
> 
> 
> We'll always need PI. The Independence part of PI is what people 
> /really/ want. They don't want multiple-PA (they can do that already 
> relatively easily). If people can not get globally-unique PI addresses 
> they will use private PI space and use address translation.

Paul, my belief system is different, which is why I've been vigorously
supporting ULAs, shim6 and the NAP draft. My belief is that if we
provide a solution set that that avoids the need for NAT with its myriad
disadvantages, enlightened self-interest will prevail.

    Brian

Delivery-date: Mon, 10 Oct 2005 16:19:00 +0000
Date: Mon, 10 Oct 2005 17:18:42 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: Mohacsi Janos <[email-masked]>, John Payne <[email-masked]>, David Meyer <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
Mail-Copies-To: [email-masked]

On Mon, 10 Oct 2005, Brian E Carpenter wrote:

> The point of shim6 is to *avoid* the need for PI-like space for 
> multihomed sites, so that we don't do to the IPv6 BGP table what 
> multihoming is doing to the IPv4 BGP table. We need IPv6 to scale 
> vastly more than IPv4, so this is essential.

The problem isn't PI addressing, it's advertising tiny prefixes in 
the routing table. PI addressing *without* global-routing-table 
visibility *would* obviously scale for routing. We just don't have a 
way to do this.

> I hope the proposed BOF will make this clearer. I personally think 
> that shim6 will be really cool for ISPs, although as Geoff says it 
> will take a while to deploy and during that time we'll need a 
> PI-like approach.

We'll always need PI. The Independence part of PI is what people 
/really/ want. They don't want multiple-PA (they can do that already 
relatively easily). If people can not get globally-unique PI 
addresses they will use private PI space and use address translation.

>    Brian

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The herd instinct among economists makes sheep look like independent thinkers.

Delivery-date: Mon, 10 Oct 2005 15:52:33 +0000
Date: Mon, 10 Oct 2005 11:48:32 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
To: Brian E Carpenter <[email-masked]>
Cc: Mohacsi Janos <[email-masked]>, John Payne <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, [email-masked], David Meyer <[email-masked]>, [email-masked], shim6-wg <[email-masked]>

On Mon, 10 Oct 2005, Brian E Carpenter wrote:

> Date: Mon, 10 Oct 2005 14:17:11 +0200
> From: Brian E Carpenter <[email-masked]>
> To: Mohacsi Janos <[email-masked]>
> Cc: John Payne <[email-masked]>,
>      Iljitsch van Beijnum <[email-masked]>, [email-masked],
>      David Meyer <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
> 
> Mohacsi Janos wrote:
> > Dear all,
> > 
> > On Tue, 4 Oct 2005, John Payne wrote:
> > 
> > 
> > I think most of the ISP who are seriously thinking about IPv6 have to 
> > have the ability to have a multihoming solution - getting PI-like 
> > address (nowadays it is /32). 

Some ISPs can get their own aggregate, some are too small and can't.

Even having your own aggregate in the global routing table and
doing IPv4 style multi-homing doesn't provide you with all of the tools 
you currently have in IPv4 multi-homing.  Distancing all the customers of
a given provider is not quite as useful as distancing one customer prefix
behind one provider.

Having commercial customers who require multi-homing but can't get their
own prefix in the global routing table is a barrier to entry, and impacts
ISPs who have many such customers.

Commercial customers with their own prefix in the global routing table and
doing IPv4 style multi-homing doesn't provide them with all of the tools
they currently have in IPv4 multi-homing.  If they are only allowed to
advertise a single aggregate, they can split load across multiple transit
providers.

> 
> The point of shim6 is to *avoid* the need for PI-like space
> for multihomed sites, so that we don't do to the IPv6 BGP table
> what multihoming is doing to the IPv4 BGP table. We need IPv6
> to scale vastly more than IPv4, so this is essential.

Yes.  We can put all of the IPv6 more specifics into the global routing
table, but current hardware won't scale to hold that.  Its not clear that
the technology to hold the larger RIB and FIB will be available in 5
years, or if it will be cost prohibitive.

If we try to solve this in some other way then de-aggregation, then we
need to make sure it is at least as functional and easy to operate as what
we have now, or no operators will want to adopt it.  

> 
> I hope the proposed BOF will make this clearer. I personally
> think that shim6 will be really cool for ISPs, although as Geoff
> says it will take a while to deploy and during that time we'll
> need a PI-like approach.
> 
>      Brian

There are many content providers who are avoiding IPv6 as they beleive it
is not yet ready for "prime time" commerical traffic as it lacks sufficent
multi-homing capabilities.  Clearly we need a multi-homing solution
now.  However I am concerned that if we allow PI addresses into the global
routing table, then we begin down the path of solving the multi-homing 
problem by de-aggregating.  In 10 years time, there may be many
de-aggregates in the global routing table.  At that time it will be much
harder to tighten the belt and get those prefixes out of the global
routing table.  

Do you think that operators of commercial networks will want to switch to
shim6?  Consider the current comfort level with the IPv4 style BGP
de-aggregate traffic engineering.  Consider that the current approach to
shim6 is less functional than the current IPv4 style multi-homing.     
Consider the the shim6 solution may be very different to operate
(configuring end hosts instead of Internet facing routers) and may
break current operational boundaries.  

Shim6 as a host multi-homing solution lends itself nicely to consumer
networks all operated by few end users with few hosts, but is more
problematic to implement it in a large commerical network.

Don't miss read me.  I'm not bashing shim6.  I'm suggesting it needs to be
as functional as what operators currently have.  

I'm also suggesting that there is a barrier to change, and if traditional
IPv4 style multi-homing is allowed to be done in IPv6 then comercial
networks may never adopt a shim6 solution.

ARIN is currently considerig PI IPv6 space.  See Policy Proposal
2005-1: Provider-independent IPv6 Assignments for End Sites:

http://www.arin.net/policy/proposals/2005_1.html

It is my belief that if this policy goes through that commercial sites
will
be unlikely adopt a shim6 solution.  

___Jason
> 
> 
> 
> For end-systems/customers/enterprises
> > might agree with upstream providers to accept more specific (and 
> > upstream can agree to exchange more specific inside country/region, but 
> > announce aggregate to global Internet) or use RFC3178 method (using 
> > tunnels) which is quite powerful technique. Any method can be 
> > implemented with careful BGP routing policy configuration.
> > The shim6 is attractive method, but requires changes in host and router 
> > IPv6 implementations and this requires at least 5 years  to be widely 
> > accepted....
> > 
> > Shim6 can be a long term solution, but shorter time-frame the 
> > operator/provider/user community can use existing methods to support/use 
> > multihoming. We can strart using it and if there is some problem we can 
> > speak up at NANOG/RIR etc meetings.
> > 
> > 
> > Regards,
> > 
> > 
> > Janos Mohacsi
> > Network Engineer, Research Associate
> > NIIF/HUNGARNET, HUNGARY
> > Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98
> > 
> > 
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

Delivery-date: Mon, 10 Oct 2005 15:06:13 +0000
Date: Tue, 11 Oct 2005 01:05:36 +1000
To: Brian E Carpenter <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-proto-00.txt
Cc: Kurt Erik Lindqvist <[email-masked]>

>Consider this node on the mailing list to agree with the interim meeting's
>decision. Sorry I couldn't be there, by the way.

speaking of the interim wg meeting held in Amsterdam this weekend, we are 
just completing the minutes today, and we anticipate posting them to the 
working group mailing list on Tuesday am (European Time)

thanks,

    Kurtis and Geoff

Delivery-date: Mon, 10 Oct 2005 15:04:06 +0000
Date: Tue, 11 Oct 2005 01:03:12 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-failure-detection-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           : Failure Detection and Locator Pair Exploration 
Design for IPv6 Multihoming
         Author(s)       : J. Arkko
         Filename        : draft-ietf-shim6-failure-detection-01.txt
         Pages           : 30
         Date            : 2005-10-10

This draft discusses the issues of detecting failures in a currently
    used address pair between two hosts and picking a new address pair to
    be used when a failure occurs.  The draft also discusses the roles of
    a multihoming protocol versus network attachment functions at IP and
    link layers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-01.txt

Delivery-date: Mon, 10 Oct 2005 12:17:54 +0000
Date: Mon, 10 Oct 2005 14:17:11 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Mohacsi Janos <[email-masked]>
CC: John Payne <[email-masked]>, David Meyer <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

Mohacsi Janos wrote:
> Dear all,
> 
> On Tue, 4 Oct 2005, John Payne wrote:
> 
>>
>> On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote:
>>
>>> NANOG = network operators in the sense of ISPs and the like. The 
>>> solution that the shim6 is working on does NOT apply to this 
>>> demographic.
>>
>>
>> Whoa there.  The NANOG community (as well as other ISP communities) is 
>> hugely affected by shim6.
>>
>> They are the ones who will be fielding customer calls about 
>> multihoming - "why can't I just setup BGP like I always have done?".  
>> Not everyone at NANOG is going to be big enough to get a /32, but most 
>> of the ISPs there are at least multihomed today.
>>
>> I for one am looking forward to both the BoF and Jason Schiller's 
>> general session topic.
>>
> 
> I think most of the ISP who are seriously thinking about IPv6 have to 
> have the ability to have a multihoming solution - getting PI-like 
> address (nowadays it is /32). 

The point of shim6 is to *avoid* the need for PI-like space
for multihomed sites, so that we don't do to the IPv6 BGP table
what multihoming is doing to the IPv4 BGP table. We need IPv6
to scale vastly more than IPv4, so this is essential.

I hope the proposed BOF will make this clearer. I personally
think that shim6 will be really cool for ISPs, although as Geoff
says it will take a while to deploy and during that time we'll
need a PI-like approach.

     Brian

For end-systems/customers/enterprises
> might agree with upstream providers to accept more specific (and 
> upstream can agree to exchange more specific inside country/region, but 
> announce aggregate to global Internet) or use RFC3178 method (using 
> tunnels) which is quite powerful technique. Any method can be 
> implemented with careful BGP routing policy configuration.
> The shim6 is attractive method, but requires changes in host and router 
> IPv6 implementations and this requires at least 5 years  to be widely 
> accepted....
> 
> Shim6 can be a long term solution, but shorter time-frame the 
> operator/provider/user community can use existing methods to support/use 
> multihoming. We can strart using it and if there is some problem we can 
> speak up at NANOG/RIR etc meetings.
> 
> 
> Regards,
> 
> 
> Janos Mohacsi
> Network Engineer, Research Associate
> NIIF/HUNGARNET, HUNGARY
> Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98
> 
> 
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

Delivery-date: Mon, 10 Oct 2005 10:46:10 +0000
Date: Mon, 10 Oct 2005 12:44:50 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Erik Nordmark <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-proto-00.txt

Erik Nordmark wrote:
> Brian E Carpenter wrote:
> 
>>>       As a result of this exchange, both A and B will know a list of
>>>       locators for each other.
>>
>>
>>
>> I would add that if the exchange fails, the initiator will then know
>> that the other end does not support shim6, and will revert to
>> standard unicast behaviour for the session.
> 
> 
> I'll add that.

Thanks

> 
>>>    o  At some point in time something fails.  Depending on the approach
>>>       to reachability detection, there might be some advise from the
>>>       ULP, or the shim (un)reachability detection might discover that
>>>       there is a problem.
>>
>>
>>
>> There's an alternative that I think should be noted:
>>
>>     Alternatively, a Traffic Engineering function requests a change
>>     in locator(s). This can be treated much like a failure condition.
> 
> 
> I'm not sure we have consensus to do that in the base protocol, as 
> opposed to some extensions beyond the base. But we should at least be 
> able to tell the peer "this locator is dead" which the introduction 
> didn't mention. So I'll add something like this:
> 
>   <t>In addition to failures detected based on end-to-end observations, 
> one endpoint
> might be know for certain that one or more of its locators is not working.
> For instance, the network interface might have failed or gone down (at 
> layer 2),
> or an IPv6 address might have become invalid. In such cases the host can
> signal its peer that this address is no longer recommended to try. Thus 
> this
> triggers something similar to a failure handling in that a new, working 
> locator
> pair must be found.</t>
>   <vspace blankLines='1' />
>   <t>The Working Group has discussed whether or not hosts can express other
> forms of locator preferences. If this is the case, a change in the 
> preferences
> can be signaled to the peer, which might make the peer choose to try a 
> different
> locator pair. Thus, this can also be treated similarely to a failure.</t>

Perfect.

> 
>>> 4.1  Context Tags and Use of Flow Label
>>
>>
>> ...
>>
>>>    o  When the context is created, each endpoint picks an unused context
>>>       tag based on the constraints above, which is also not used as a
>>>       flow label for the set of locators.
>>
>>
>>
>> Now here I have a problem, which is related to a long discussion
>> between Erik and me some months ago.
> 
> 
> The Interim Meeting in Amsterdam has a recommendation in this area that 
> will simply our lives (including that of the document editor). That is 
> to not use the flow label or overloading of the protocol type values 
> (for "foo over shim6").

I support this. I think it's the best solution. I believe we've
established that the flow label approach was in the best case very
hard to get right and quite complex.

> 
> Instead, after a failure (when locator pair is not the ULID pair), the 
> ULP packets will have an 8 byte shim6 extension header.
> 
> The folks at the Interim Meeting believe that we can later remove this, 
> by adding some additional end-to-end signaling (basically, the hosts can 
> agree that certain packets can avoid this header) and that this doesn't 
> need to use the flow label either. But details are for further study.
> Of course, this and other design decisions need to be verified with the 
> shim6 mailing list.

Consider this node on the mailing list to agree with the interim meeting's
decision. Sorry I couldn't be there, by the way.

     Brian

Delivery-date: Sun, 09 Oct 2005 22:24:23 +0000
Date: Sun, 09 Oct 2005 15:23:32 -0700
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-proto-00.txt

Brian E Carpenter wrote:
>>       As a result of this exchange, both A and B will know a list of
>>       locators for each other.
> 
> 
> I would add that if the exchange fails, the initiator will then know
> that the other end does not support shim6, and will revert to
> standard unicast behaviour for the session.

I'll add that.

>>    o  At some point in time something fails.  Depending on the approach
>>       to reachability detection, there might be some advise from the
>>       ULP, or the shim (un)reachability detection might discover that
>>       there is a problem.
> 
> 
> There's an alternative that I think should be noted:
> 
>     Alternatively, a Traffic Engineering function requests a change
>     in locator(s). This can be treated much like a failure condition.

I'm not sure we have consensus to do that in the base protocol, as 
opposed to some extensions beyond the base. But we should at least be 
able to tell the peer "this locator is dead" which the introduction 
didn't mention. So I'll add something like this:

   <t>In addition to failures detected based on end-to-end observations, 
one endpoint
might be know for certain that one or more of its locators is not working.
For instance, the network interface might have failed or gone down (at 
layer 2),
or an IPv6 address might have become invalid. In such cases the host can
signal its peer that this address is no longer recommended to try. Thus 
this
triggers something similar to a failure handling in that a new, working 
locator
pair must be found.</t>
   <vspace blankLines='1' />
   <t>The Working Group has discussed whether or not hosts can express other
forms of locator preferences. If this is the case, a change in the 
preferences
can be signaled to the peer, which might make the peer choose to try a 
different
locator pair. Thus, this can also be treated similarely to a failure.</t>

>> 4.1  Context Tags and Use of Flow Label
> 
> ...
> 
>>    o  When the context is created, each endpoint picks an unused context
>>       tag based on the constraints above, which is also not used as a
>>       flow label for the set of locators.
> 
> 
> Now here I have a problem, which is related to a long discussion
> between Erik and me some months ago.

The Interim Meeting in Amsterdam has a recommendation in this area that 
will simply our lives (including that of the document editor). That is 
to not use the flow label or overloading of the protocol type values 
(for "foo over shim6").

Instead, after a failure (when locator pair is not the ULID pair), the 
ULP packets will have an 8 byte shim6 extension header.

The folks at the Interim Meeting believe that we can later remove this, 
by adding some additional end-to-end signaling (basically, the hosts can 
agree that certain packets can avoid this header) and that this doesn't 
need to use the flow label either. But details are for further study.
Of course, this and other design decisions need to be verified with the 
shim6 mailing list.

    Erik

Delivery-date: Sat, 08 Oct 2005 16:29:18 +0000
Date: Sat, 08 Oct 2005 18:28:06 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-proto-00.txt

This is a bit late as the discussion has presuambly taken
place, but here are my main comments.

Firstly, it's great to see this draft. Real progress.

> 4.  Protocol Overview
...
> 
>       As a result of this exchange, both A and B will know a list of
>       locators for each other.

I would add that if the exchange fails, the initiator will then know
that the other end does not support shim6, and will revert to
standard unicast behaviour for the session.

...
> 
>    o  At some point in time something fails.  Depending on the approach
>       to reachability detection, there might be some advise from the
>       ULP, or the shim (un)reachability detection might discover that
>       there is a problem.

There's an alternative that I think should be noted:

     Alternatively, a Traffic Engineering function requests a change
     in locator(s). This can be treated much like a failure condition.

...
> 4.1  Context Tags and Use of Flow Label
...
>    o  When the context is created, each endpoint picks an unused context
>       tag based on the constraints above, which is also not used as a
>       flow label for the set of locators.

Now here I have a problem, which is related to a long discussion
between Erik and me some months ago.

Firstly, RFC 3697 needs to be the normative (not informative) reference
for this discussion.

Secondly, I think the above bullet is wrong. I think these should be
the basic principles:

1. The granularity of multihoming fate should be identically equal to
the granularity of flow labels. Whatever set of packets a source ULP
chooses to assign the same flow label is the set of packets that
will get shim6'ed together.

2. If outgoing packets enter the top of the shim with a given flow label,
that should be the shim6 context identifier for that set of packets
(modulo a given pair of ULIDs).

3. If outgoing packets enter the top of the shim with a zero flow label,
the shim creates one (as you decsribe and according to the rules in 3697).

Now that still leaves an issue, if the ULP mechanism for assigning flow
labels happens to reuse a flow label in a way that breaks the restriction
that a flow label is unique to a shim6 locator set. I think that needs an
extra flow label assignment rule as a normative extension to 3697 -
in a shim6'ed host, the shim must register flow labels in the flow label
assignment mechanism in such a way that this cannot happen. (And there
may be a race condition).

If you don't do something like the above, I don't see how the RFC 3697
requirement for e2e delivery of flow labels can be respected. There is still
one glitch - in the case of a zero flow label, does 3697 require you to
restore it to zero? 3697 didn't anticipate the existence of a shim, so
that point isn't clear to me.

These are first reactions in haste, hope they make sense.

    Brian

Delivery-date: Sat, 08 Oct 2005 06:08:15 +0000
Date: Sat, 08 Oct 2005 09:07:30 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: new version of the failure detection draft

A new version of the failure detection draft
can be found here:

http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-01.txt

and diffs here:

http://ietf.levkowetz.com/tools/rfcdiff/rfcdiff.pyht?url1=http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-00.txt&url2=http://www.arkko.com/publications/shim6/draft-ietf-shim6-failure-detection-01.txt

--Jari

Delivery-date: Fri, 07 Oct 2005 20:39:02 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: delay as a metric, aggregation
Date: Fri, 7 Oct 2005 22:38:32 +0200
To: Jari Arkko <[email-masked]>

On 6-okt-2005, at 16:15, Jari Arkko wrote:

> I liked your idea of comparing the nominal delay to
> actual delay.

Thanks.

Although this is not an intrinsic quality, in practice delay is  
almost completely dependent on the full path between two endpoints,  
while bandwidth and packet loss are respectively so high and so low  
in the core that they're almost completely dependent on the part of  
the network local to either endpoint.

> The synthetic coordinates idea from Cedric was a very interesting
> one as well. I'd like to play with that if it became available. But  
> I fear
> that DNS storage etc. is a deployment barrier.

Well, if it is (might be, might not be, dynamic DNS is your not very  
secure friend), my earlier idea of having delay measuring beacons may  
be useful. If we assume that ISPs will typically have one or more of  
these beacons, and the beacons communicate, it should be possible to  
ask the local beacon for the estimated delay towards a certain  
prefix. The local beacon would have to to which remote beacon this  
prefix maps, and then sends back the nominal delay for that prefix.

This can be combined with Cedric's work by having the ultimate  
destination publish its distance to one or more close by beacons in  
the DNS. Or if this is a problem have the destination register its  
distance with the beacon, but then inter-beacon communication would  
end up being a shadow DNS...

> Anyway, I see two bigger issue here. The first one is the division
> of work between IP and transports. If we are sure that we
> can develop a simple scheme that works well, it would make sense
> adding to that to the IP layer. But if we find out later that
> we need to take into account variations in congestion level,
> packet loss, etc., we may find ourselves adding a lot of
> functionality to try to mimic what transports are already
> doing.

Well, transports aren't doing all that much currently...

But your point that we should be wary of feature creep is well taken.  
I think we need to have a priority mechanism similar to what SRV  
records have and a generic TLV mechanism for future extension, but  
that should be enough as a mandatory part of the shim.

> An approach that does not have this drawback would
> be providing feedback from transports and ULPs to the
> shim6 so that when they say "unacceptable", Shim6 would
> attempt to find another path.

Hm, this only works well if you need a certain service level and  
nothing more than that. Many applications like to take as much as  
they can get. For these, there is no "unacceptable".

> This would still leave the
> problem of the exploration process finding the right
> alternative with a high probability of success. I'm not sure
> we know how to do that.

Right. The only thing we know is that this is going to involve:

- communicating values and capabilities between the correspondents
- sending probe packets
- rehoming sessions

As long as the shim can accommodate all of these, the actual  
implementation of the exploration process can be left TBD.

Delivery-date: Fri, 07 Oct 2005 16:10:08 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-bagnulo-shim6-addr-selection-00.txt 
Date: Fri, 7 Oct 2005 18:09:17 +0200
To: marcelo bagnulo braun <[email-masked]>

On 4-okt-2005, at 9:57, marcelo bagnulo braun wrote:

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

    We do not assume that the DNS is dynamic:
    there will be situations in which both A:X and B:X are published,
    while in fact only one is reachable.

Such an assumption would be impossible, because even if the DNS could  
be updated in time (ie no caching) it's possible that Y can reach  
both A:X and B:X while for Z only A:X is reachable and B:X is  
unreachable.

Small nits:

- on page 3 the reference topology has ( A ) and ( B ) but then (C).  
The dashes also don't align to objects in a consistent manner.

- on page 3 it says "Host X has to global IPv6 addresses" but you  
probably mean "two"

- also, isn't using A and B for hosts and X and Y for ISPs more  
common (or is that just me?)

- it says "wit" somewhere

- "The first option is to simply let the upper layers to handle" the  
"to" is superfluous here

The big stuff:

- please don't start new headings with a new "page", it wastes time  
when reading on the screen and paper when the document is printed.

Basically you say that because applications are supposed to try all  
available destination addresses, there is no problem when a  
destination address doesn't work, but since applications don't try  
different source addresses a broken source address is problematic.

I agree that applications should try all addresses, and it looks like  
we have to extend this to trying all source/dest combinations. That  
can be painful. However, many applications DO NOT try all addresses.  
I think it would be good if the shim would be able to pick up the  
slack in these cases rather than depend on correct application behavior.

One of my main concerns is the time all this trying of alternative  
addresses in ULPs is going to take. In many cases, the shim will know  
that something isn't going to work much faster than even an expedited  
ULP timeout. For instance, AFAIK hosts are supposed to ignore ICMP  
errors during (TCP) session creation, but the shim can probably react  
to these without too much trouble. Also, when for the last N seconds  
there haven't been successful interactions using a certain address,  
the shim may reach the conclusion that this address is no longer  
reachable and not waste time with it for initial packets. The shim  
could transfer this knowledge to the RFC 3484 mechanisms.

5.1.  Proactive mechanisms

    In this case, two mechanisms are needed: first, a mechanism to  
detect
    the outage and then a mechanisms to inform the host about which
    prefixes should be used in the source address for the different
    destinations.

I don't really understand what you're talking about. If K has a  
broken address, does this mean that K knows this or that L knows this???

    There are several mechanisms that can be used to detect the outage.
    For instance, if any routing protocol is used between the ISP and  
the
    multihomed site, such protocol can be used to detect the outage.  In
    any case, it is possible to use a periodic ICMP echo request for
    detecting the outage on direct links.

There are better ways than pings for this.

    We propose to use the "preferred" lifetime to indicate whether
    addresses derived from the prefix can be used as source address in
    multihomed networks.  When a prefix is temporarily not available
    routers MUST advertise a null preferred lifetime for that prefix.

Agree. However, I would use "zero" rather than "null" here to avoid  
confusion.

    This solution is sufficient when the site is composed of a single
    link; for more complex sites with multiple subnets, we need a
    mechanism with a broader scope than Router Advertisement.  There are
    two available candidates that provide the required fucntionality:  
the
    Router Renumbering protocol [3] and the prefix delegation option
    defined for DHCP [8].

Both not used today, although prefix delegation may be taken up in  
the future.

Why not come up with something new for this? Such as a site scoped  
multicast message?

    In this scenario a mechanism like NAROS [6] can be used.  In this
    mechanism, a server acquires the reachability information available
    in the inter-domain routing system using BGP.

This is mostly useless due to aggregation in BGP.

    the retransmission service provided by the IP layer

:-)

You are trying to build shim functionality outside the shim...  
Doesn't make much sense to me.

Apologies for not reviewing this draft sooner.

Iljitsch

Delivery-date: Fri, 07 Oct 2005 15:55:42 +0000
Date: Fri, 07 Oct 2005 08:55:46 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Jari Arkko <[email-masked]>, shim6 <[email-masked]>
Subject: Re: CUD and FBD

Iljitsch van Beijnum wrote:

> Rather than choose CUD or FBD and expect vendors to implement this  
> correctly, we can define the probing such that it gives implementers  
> maximum flexibility. This has the advantage that we don't have to  spend 
> large amounts of brainpower coming up with the perfect solution  before 
> there is operational experience, and that implementers can  begin with 
> something simple and extend it later.
> 
> The idea is that we basically specify CUD as the basic approach. So  
> first of all, when there is no outgoing traffic, nothing happens.  Also, 
> in the presence of positive ULP feedback nothing happens. When  there is 
> outgoing traffic but no positive feedback, the shim layer  periodically 
> sends out a probe. The other end sends back a reply when  it sees the 
> probe.

Why can't we just pick FBD and be done with it?
It seems to do the same job as CUD, and doesn't cause extra packets when 
the ULPs don't give any feedback.

Or am I missing some downside of FBD that makes it inappropriate as the 
one and only way?

    Erik

Delivery-date: Fri, 07 Oct 2005 15:30:59 +0000
Date: Fri, 07 Oct 2005 04:43:36 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: delay as a metric, aggregation

Jari Arkko wrote:

> Anyway, I see two bigger issue here. The first one is the division
> of work between IP and transports. If we are sure that we
> can develop a simple scheme that works well, it would make sense
> adding to that to the IP layer. But if we find out later that
> we need to take into account variations in congestion level,
> packet loss, etc., we may find ourselves adding a lot of
> functionality to try to mimic what transports are already
> doing. An approach that does not have this drawback would
> be providing feedback from transports and ULPs to the
> shim6 so that when they say "unacceptable", Shim6 would
> attempt to find another path. This would still leave the
> problem of the exploration process finding the right
> alternative with a high probability of success. I'm not sure
> we know how to do that. For instance, if the transports say
> that while the current path works its too small bandwidth,
> we test another one, switch to that, and then find out that
> also is too small. Perhaps delay can act as a metric here,
> but I'd prefer to see some experimental results to understand
> how well it works.

One way to carve this up between the transports and the shim is to have 
the shim be able to tell it's peer the  priority and weight for its 
locators. This would then allow the transports on A to tell the shim on 
A that A1 is now higher priority than A2, and the shim will inform B of 
this change.

In such a scheme we can end up with multiple sets of locators
	locator	priority	weight
	A1	1		50
	A2	1		50
	A3	2		33
	A4	2		33
	A5	2		33

which would imply that if either A1 or A2 is working they would be 
preferred over the locators in the second set. (And within each set the 
weights suggest an even split.)
If A then says that A5 now has priority 0, then presumably B should try 
to switch to A5.

> The second issue is our ambition level with load balancing
> functionality in Shim6. If the ambition level is so high that
> we try to get the same session over two paths, then this
> impacts transports. But even if the ambition level is
> running different sessions in different paths, we
> would still have to deal with congestion in some manner.
> Ideally, we'd be adding sessions to a path so that
> the existing sessions do not have to slow down.

I've never had that fancy level of ambition.
(1) The minimum (which the proto draft ia alluding to) is that two 
separate hosts in site A which communicate with site B (or a particular 
host in site B) should not be forced to use the same locator prefix as 
the destination when sending to B.

(2) I think we can easily provide the ability for different context that 
use different ULID pairs between two hosts to use different locators.
For instance, A (locators A1, A2) and B (locators B1, B2, B3) might end 
up with TCP connections between ULID <A1, B1> and ULID <A2, B3>.
There is no reason we need to force those ULID pairs (between the same 
hosts) to use the same locator pair; they'll be different host-pair 
contexts with different context tags in the current model.

There are at least two more levels of ambitions I can distinguish:
(3) Different ULP sessions/connections between the same ULID pair can 
use different locator pairs.

(4) A single ULP session/connection spread over a different locator pairs.

FWIW I think we should leave #4 out of scope. I the transport area wants 
to explore this that's ok with me, but it feels way to early to think 
about how to add support for this in the shim.

#3 might require some care in the reachability detection, since it 
requires a ULID pair to be able to verify that two different locator 
pairs are working at the same time, without accidentally concluding that 
just because some traffic gets through on one locator pair, both pairs 
are working.
But apart from that it seems like a local matter between the transports 
and the shim (For instance, a transport can optionally indicate its 
prefered locator pair for each packet that is passed down to IP.)

For #3 I'm far from convinced that just because the transport prefers 
A1->B2 for some connection, that this should imply that this connection 
will use B2->A1 in the reverse direction. I see several issues with this:
  - It doesn't seem useful if we are going to handle the unidirectional 
locator pair reachability problem, since the locator pairs in the two 
directions must be able to be different in that case.
  -  The shim would need a "language" to express what ULP packets the 
peer should send over which locator pair, which certaily is added 
complexity.
  - The shim would have to cope with the transport passing down 
preferences with each packet (as suggested above under #3) *and* the 
peer shim expressing which ULP packets should use which locator pair. 
Thus the shim (which has no ULP knowledge) needs to be able to resolve 
those potentially conflicting preferences.

   Erik

Delivery-date: Fri, 07 Oct 2005 15:30:29 +0000
Date: Fri, 07 Oct 2005 08:18:08 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-proto-00.txt

Jari Arkko wrote:

> Technical:
> 
> Missing a discussion on the relationship of the shim6
> processing wrt other processing that is taking place
> at the IP layer, including at least IPsec but probably
> also Mobile IPv6. I know from past experience that
> its quite hard to define the relationships and processing
> order correctly, and I suspect that its increasingly hard
> for shim6.

That's covered in abbreviated form (the string "TBD" :-) )

Seriously, the intent is to have the same placement of the shim as we've
discussed before, and flush out the details a bit more than in the
l3shim draft.

> Also, what is the relationship of Shim6 processing to
> things in the host that depend on literal addresses,
> such as IPsec policies?

With a l3shim below the IP endpoint sublayer, the IPsec policies operate
on ULIDs.

> Another missing discussion: the document refers to
> SCTP as if it would be obvious how it can use Shim6. I'm
> not sure that's the case. Or at least its not obvious to me :-)

I suspect we don't need to do anything special to "not break" SCTP. But
there are choices whether SCTP would see all locators as ULIDs or not.
(If it sees all of them, then SCTP might fail over between ULIDs while
the shim underneath takes a ULID-pair context and fails it over to
another locator pair, which is probably a bit suboptimal.)
But I think it would make sense to put this type of discussion in a
short separate draft, since this makes it easier to get feedback from
the SCTP folks (and transport folks in general.)

> Yet another missing discussion: is there some interaction
> with this protocol and the protocol defined in Marcelo's
> draft that talked about communication with non-shim6
> peers? It would appear that some aspects (e.g. input from
> RAs) is common.

That relates to reachability detection and exploration, which I think
the WG decided to put in a separate draft. It probably makes sense to
keep the packet formats in one place, but define the detailed behavior
for those items in a separate one.

> And one more: the document is relatively silent on
> (un)reachability detection mechanisms beyond shim6-based
> probing. We do have ND(NUD), L2, etc. mechanisms that
> should be taken into account. If your L2 tells you that its
> lost the connection, there's no point in probing at L3,
> we need to find another interface!

See above.

>>   multihoming can be provided for IPv6 with failover and load spreading
>>   properties
>>
> I'm a bit concerned that we have not figured out all the details
> regarding load spreading.

FWIW this text is what I named level (0) in another email today.
But the text needs to be flushed out.

>>   In addition, the non-shim6 messages, which we call payload packets,
>>   will not contain the ULIDs after a failure.  This introduces the
>>   requirement that the <peer locator, local locator, local context tag>
>>   MUST uniquely identify the context.  Since the peer's set of locators
>>   might be dynamic the simplest form of unique allocation of the local
>>   context tag is to pick a number that is unique on the host.  Hosts
>>   which serve multiple ULIDs using disjoint sets of locators can
>>   maintain the context tag allocation per such disjoint set.
>>  
>>
> Not sure if this always needs to be true.
> It might be that the shim6 failover protocol signaling
> is used to tell the peer what the new locators are. If
> that's the case, then the local context tag alone does
> not need to be unique, you could rely also on the
> addresses.

Yes, the language was meant more as an example than a requirement.

But  I'm not sure what the actual requirement is. For example,
  - the packets sent from A to B for ULID A1 to B1 use context tag X
    B knows that A has locators A1, A2.
  - there is a request from ULID C1 to B1, which makes B allocate a new
    context tag. Suppose B chooses tag X.
  - Later C1 tells B that it has locators A1, A2, C1.
    Now B has a potential problem, since later the C1 to B1 context might
    switch to using the same locators as the A1 to B1 context.

It seems like B must know all the possible future locators of a peer
before allocating a context tag, *or* B must have a way of refusing a
peer to use a locator for a context in order to avoid confusion.

So a question is whether we need to have a protocol mechanism by which a 
host can refuse that a peer use of its locators in the locator set for 
the context.

> Also, there seems to be security issue in using just
> the context tag to do the demux. (Or is there some
> crypto hash somewhere too?) If I learn or guess
> your tag, does that mean that I can start sending
> traffic that appears to come from you, even if I
> use a different source IP and my host is under
> ingress filtering restrictions?

The context lookup on the receiver is based on <source locator,
destination locator, context tag>, thus this is stronger than today
where it is sufficient to spoof the source address; you also need to
find the right context tag to be able to inject packets.

> I'd like to understand this better. Is the information flow
> always from the host to the middleboxes and routers?
> If yes, then the host can keep its choices about the flow
> labels. If not, then we may have a problem.

I'm not sure if RFC 3697 specifies that level of constraint for new flow 
signaling mechanisms. For the unsignaled traffic the host can pick 
whatever flow label it wants.

I think RSVP assumes that the host would provide the flow label (as it 
provides IP addresses and port numbers to specify an IPv4 flow).
Any idea if NSIS is different?

> In a crash followed by reboot it does not help that shim6
> recovers the state. TCP and SCTP state is gone anyway.
> For UDP and ICMP shim6 recovery would help.

To the contrary I think it is required, so that in the TCP case there 
can be a reset going back.

If the sender is using shim state and locators different than the ULIDs, 
but the receiver has lost the shim state, and there is no indication in 
the received packet that it must be processed by the shim, then IP layer 
will just pass it up to the ULP. Since the pseudo-header checksum is 
different, this will result in a ULP checksum error.

So without *any* recovery mechanism, TCP would send and never hear a RST 
back. If TCP then times out and gives up, even if it creates a new 
connection (between the same ULID pairs), the sender would still apply 
the shim to the TCP SYN packets, and the same checksum error would be 
the result.

So for the crash and reboot case we need some mechanism that can be used 
to indicate that the context state is gone.
Perhaps a "do you still have the context" every minute or so when other 
packets are being sent?

But there is another potential reason for the protocol field 
overloading, which I haven't fully worked out.

With an overloaded protocol field, the order in which the receiver does 
its work is specified in the chain of protocol fields/extension headers 
in the packet. (In effect, the overloaded "udp over shim6" protocol 
field acts as an indication that there is a zero length shim6 extension 
header followed by a UDP header.) If we don't have this, then at what 
point in time would the receiver look for a context based on the <source 
locator, destination locator, flow label>? (If there might be routing 
header type 2 or home address option, it might be critical to do this 
lookup at the correct place.)

>>   Thus with 7 or so additional protocol field values we can do a
>>   reasonable job of overloading the flow label field and get detection
>>   of lost context state.
>>  
>>
> This is primarily an optimization. I wonder if it would make
> sense to limit the optimization to the 80% useful case which
> to me would be TCP, ESP, UDP, or even less. No sense in
> optimization ICMP messages, I think.

I guess we first need to decide whether we want this protocol field 
overloading, or whether we do an 8 byte extension header when the 
locators are not the ULIDs.

> It isn't clear to me how this would be done. Presumably
> its the application that is going through the IPs retrieved
> from DNS, not the IP layer. Is this something that we
> need to handle?

I think we need to say home failure during initial communication is 
handled. I'm not certain the extent to which we need to optimize this 
case, hence I don't know if the shim needs to be involved at all.

> It might be possible to combine these functions. But lets
> do the individual design first for each, and combine later
> if possible.
> 
> Also, the assistance from payload packets in the explore
> phase is not discussed.

Ack.

> Finally, I hope everyone is OK with the design that is
> extremely tightly integrated with IPv6. I know its
> in our charter, but I still worry about it since I see
> so many things that eventually had to work on both
> v6 and v4 (people working on mobile IP now to run on both,
> IPsec has done so for a very long time, IP multimedia
> systems had to run on v4 too, etc). We won't be able
> to do this for Shim6.

We don't have an approach to securing IPv4 since HBA/CGA doesn't apply.
(The only thing that multi6 discussed that would fit that would be to 
use the NOID-style DNS verification.)

So the ULIDs have to be IPv6 addresses.
For CGA, perhaps there can be locators that are IPv4-mapped addresses 
(i.e., just IPv4 addresses).

    Erik

Delivery-date: Fri, 07 Oct 2005 15:29:58 +0000
Date: Fri, 07 Oct 2005 04:20:56 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: CUD and FBD

Jari Arkko wrote:

> Not sure I like either one of these options. Preferrably, the probing 
> frequency
> would depend on whether you have something to send or not. For instance, if
> we don't have any payload packets to send, the frequency = n and if we 
> do have
> packets to send, it would m, m << n. If you combine this with the ULP 
> feedback
> and packet reception in CUD, we have a mechanism that normally does not 
> need
> extra probes during traffic and which generates a very small amount of 
> traffic
> when its idle.

We can do better than that. When there is no data traffic neither CUD or 
FBD should need to send any extra packets. I think we only care about 
reachability when we have packets to send or receive, so this should be ok.
(If we want to detect that a peer might have lost shim state, it might 
be desirable to send some "context verification" type probe 
occasionally, but functionally that's different than verifying 
reachability for the current locator pair.)

   Erik

Delivery-date: Fri, 07 Oct 2005 13:49:17 +0000
Cc: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CUD and FBD
Date: Fri, 7 Oct 2005 15:48:18 +0200
To: marcelo bagnulo braun <[email-masked]>

On 7-okt-2005, at 10:28, marcelo bagnulo braun wrote:

>>> In CUD, each time there is an idle period, 2 packets are  
>>> generated, one in each direction.
>>> In FBD, each time there is an idle period, i packet is generated

>> Not sure I like either one of these options. Preferrably, the  
>> probing frequency
>> would depend on whether you have something to send or not. For  
>> instance, if
>> we don't have any payload packets to send, the frequency = n and  
>> if we do have
>> packets to send, it would m, m << n.

In CUD, if we have nothing to send we don't probe either.

In FBD, the situation where we have nothing to send (but we do  
receive packets from the other end) is exactly the situation where we  
need to send keepalives to let the other side know we're still there.

>> If you combine this with the ULP feedback
>> and packet reception in CUD, we have a mechanism that normally  
>> does not need
>> extra probes during traffic and which generates a very small  
>> amount of traffic
>> when its idle.

Both FBD and CUD are quiet when the session is idle in both directions.

> - an endpoint that is sending but not receiving in CUD will result  
> in an additional overhead of 2 signaling packets one in each  
> direction periodically , while,
> - an endpoint that is sending but not receiving in FBD will result  
> in an additional overhead of 1 signaling packet in the incoming  
> direction  periodically

Right.

>> I think we can assume that an optimized Shim6 implementation gets  
>> ULP feedback.
>> NUD needs it anyway, so its not a big assumption.

Maybe there will be some sort of feedback, but I'm not convinced it  
will help us all that much. AFAIK, NUD results in a significant  
number of additional neighbor solicitations.

However, I want to reiterate something I talked about earlier:

Rather than choose CUD or FBD and expect vendors to implement this  
correctly, we can define the probing such that it gives implementers  
maximum flexibility. This has the advantage that we don't have to  
spend large amounts of brainpower coming up with the perfect solution  
before there is operational experience, and that implementers can  
begin with something simple and extend it later.

The idea is that we basically specify CUD as the basic approach. So  
first of all, when there is no outgoing traffic, nothing happens.  
Also, in the presence of positive ULP feedback nothing happens. When  
there is outgoing traffic but no positive feedback, the shim layer  
periodically sends out a probe. The other end sends back a reply when  
it sees the probe.

So far so good.

But in order to optimize for the situation where there is no ULP  
feedback and to reduce the number of probes, a host may indicate that  
it supports two additional capabilities in the probe:

1. That if the other end sees our traffic, it may send a "probe  
reply" without having received a probe first at X second intervals  
for Y probes or seconds.

2. That if the other end sent any other type of packet in the last Z  
seconds, it may suppress the probe reply.

If both ends support both these options this effectively means  
they'll switch to FBD for some time. (Timeout is probably a good idea  
to keep broken implementations from sending unsolicited probes for  
all eternity.) However, if one end doesn't support one or both of the  
additional capabilities nothing happens and we're still at CUD.

So basically this is CUD with the option of moving to FBD later. This  
makes sense unless we can be more or less absolutely certain we  
either never need to move to FBD, or that FBD is at least as good and  
probably better than CUD. Without having done any IP stack  
programming I believe that CUD (possibly with fairly limited ULP  
advice) is easier to implement while FBD is probably more efficient.

I assume we can arrive at a decision on this after some discussion  
this weekend.

Delivery-date: Fri, 07 Oct 2005 08:27:45 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CUD and FBD
Date: Fri, 7 Oct 2005 10:28:06 +0200
To: Jari Arkko <[email-masked]>

El 06/10/2005, a las 22:21, Jari Arkko escribi=F3:

> marcelo bagnulo braun wrote:
>
>> So, in FBD each node has a clear view about a failure in their=20
>> incoming path, while in CUD, each node can detect a failure but it is=20=

>> not certain of which direction is affected.
>>
>> This difference may not be relevant, depending on which are the=20
>> following steps.
>> In FBD, the node that has detected the outage needs to inform the=20
>> other end about the failure, in a reliable manner. This may result in=20=

>> starting the full path exploration procedure as described in the=20
>> draft, so that the other end starts the procedure itself.
>> In CUD, the behaviour is likely to be the same, since the node that=20=

>> has detected the outage does not knows which direction has failed, so=20=

>> both nodes need to perform the full path exploration procedure.
>> So, i think that the result in both mechanisms is similar.
>
> Agreed.
>
>> - Overhead
>>
>> In CUD, each time there is an idle period, 2 packets are generated,=20=

>> one in each direction.
>> In FBD, each time there is an idle period, i packet is generated
>
> Not sure I like either one of these options. Preferrably, the probing=20=

> frequency
> would depend on whether you have something to send or not. For=20
> instance, if
> we don't have any payload packets to send, the frequency =3D n and if =
we=20
> do have
> packets to send, it would m, m << n. If you combine this with the ULP=20=

> feedback
> and packet reception in CUD, we have a mechanism that normally does=20
> not need
> extra probes during traffic and which generates a very small amount of=20=

> traffic
> when its idle.
>

right i am sorry for my really poor wording above (it is just that i=20
fail to state the underlaying assumptions)

When i said idle i meant that one end is sending but it is not=20
receiving anything, like an unidirectional flow.
So, if we are in a situation of an unidirectional flow, and no ULP=20
feedback (which is worse case when considering the amount of probes=20
needed) then it results what i pointed above i.e.:

- an endpoint that is sending but not receiving in CUD will result in=20
an additional overhead of 2 signaling packets one in each direction=20
periodically , while,
- an endpoint that is sending but not receiving in FBD will result in=20
an additional overhead of 1 signaling packet in the incoming direction =20=

periodically

>> - ULP interaction
>>
>> As defined in the draft, CUD requires ULP feedback in order to=20
>> greatly reduce overhead. However, as i mentioned above, i think that=20=

>> a workaround can be used to deal with this issue.
>
> I think we can assume that an optimized Shim6 implementation gets ULP=20=

> feedback.
> NUD needs it anyway, so its not a big assumption.
>
>>
>> IMHO, both mechanisms can benefit from negative ULP feedback in a=20
>> similar way, since CUD wouldn't need to wait for Tu and FBD wouldn't=20=

>> have to wait for n*t. Probably, the benefit is much greater in FDB.
>
> Yes.
>
>> So, as far as i can see, both mechanisms behave quite similarly.=20
>> Probably, the main difference is w.r.t. the overhead, where FBD is=20
>> superior.
>
> The mechanisms are very close indeed, particularly if you consider=20
> that both
> benefit from some ULP feedback. What you wrote later:
>
>> In this extended CUD scheme there are three elements in the failure=20=

>> detection:
>> - ULP feedback
>> - incoming traffic
>> - explicit reachability tests
>
> seems to make a lot of sense to me. Does the no-exponential-backoff=20
> property
> hold for this too (except for the 3rd item)?
>

I think so, i only see the exponential backoff in the probing mechanisms

regards, marcelo

> --Jari
>

Delivery-date: Thu, 06 Oct 2005 22:40:30 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: delay as a metric, aggregation
Date: Fri, 7 Oct 2005 00:39:55 +0200
To: Fred Baker <[email-masked]>

On 6-okt-2005, at 21:51, Fred Baker wrote:

> Delay is a good metric as long as it is relatively stable. There is  
> ample experience to show that delays change in time, and when the  
> difference in two delays is comparable to the time implied by a  
> mean queue depth, can result in route oscillation. There are ample  
> research papers on the subject back to 1980-or-so, when delay was  
> in fact the primary metric used in ARPANET routing.

This is of course true, but I don't think it's as relevant today as  
it was 25 or even 10 years ago, because bandwidth has gone up so  
much. In order to incur 10 ms queuing delay on a 1 Gbps link, you  
need to have a queue of 833 packets of 1500 bytes (ignoring  
overhead). To arrive at an average queue depth of that size the line  
utilization has to be 99.88%. Although nothing is impossible, this is  
a very unlikely situation.

Also, I'm not sure many people even use this much buffer memory for a  
link. I believe Cisco uses a standard buffer of 75 packets, although  
this may be different for very high speed links.

Last but not least, if people use RED then TCP and other transports  
that use similar congestion control mechanisms will be slowed down  
anyway.

> What one wants to know is that one is getting among the best  
> service options available, but not that it is for sure the very  
> best available option at this instant.

Right.

Delivery-date: Thu, 06 Oct 2005 20:21:42 +0000
Date: Thu, 06 Oct 2005 23:21:34 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: CUD and FBD

marcelo bagnulo braun wrote:

> So, in FBD each node has a clear view about a failure in their 
> incoming path, while in CUD, each node can detect a failure but it is 
> not certain of which direction is affected.
>
> This difference may not be relevant, depending on which are the 
> following steps.
> In FBD, the node that has detected the outage needs to inform the 
> other end about the failure, in a reliable manner. This may result in 
> starting the full path exploration procedure as described in the 
> draft, so that the other end starts the procedure itself.
> In CUD, the behaviour is likely to be the same, since the node that 
> has detected the outage does not knows which direction has failed, so 
> both nodes need to perform the full path exploration procedure.
> So, i think that the result in both mechanisms is similar.

Agreed.

> - Overhead
>
> In CUD, each time there is an idle period, 2 packets are generated, 
> one in each direction.
> In FBD, each time there is an idle period, i packet is generated 

Not sure I like either one of these options. Preferrably, the probing 
frequency
would depend on whether you have something to send or not. For instance, if
we don't have any payload packets to send, the frequency = n and if we 
do have
packets to send, it would m, m << n. If you combine this with the ULP 
feedback
and packet reception in CUD, we have a mechanism that normally does not need
extra probes during traffic and which generates a very small amount of 
traffic
when its idle.

> - ULP interaction
>
> As defined in the draft, CUD requires ULP feedback in order to greatly 
> reduce overhead. However, as i mentioned above, i think that a 
> workaround can be used to deal with this issue.

I think we can assume that an optimized Shim6 implementation gets ULP 
feedback.
NUD needs it anyway, so its not a big assumption.

>
> IMHO, both mechanisms can benefit from negative ULP feedback in a 
> similar way, since CUD wouldn't need to wait for Tu and FBD wouldn't 
> have to wait for n*t. Probably, the benefit is much greater in FDB.

Yes.

> So, as far as i can see, both mechanisms behave quite similarly. 
> Probably, the main difference is w.r.t. the overhead, where FBD is 
> superior.

The mechanisms are very close indeed, particularly if you consider that both
benefit from some ULP feedback. What you wrote later:

> In this extended CUD scheme there are three elements in the failure 
> detection:
> - ULP feedback
> - incoming traffic
> - explicit reachability tests 

seems to make a lot of sense to me. Does the no-exponential-backoff property
hold for this too (except for the 3rd item)?

--Jari

Delivery-date: Thu, 06 Oct 2005 19:52:09 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: delay as a metric, aggregation
Date: Thu, 6 Oct 2005 12:51:37 -0700
To: Jari Arkko <[email-masked]>

Delay is a good metric as long as it is relatively stable. There is  
ample experience to show that delays change in time, and when the  
difference in two delays is comparable to the time implied by a mean  
queue depth, can result in route oscillation. There are ample  
research papers on the subject back to 1980-or-so, when delay was in  
fact the primary metric used in ARPANET routing. What one wants to  
know is that one is getting among the best service options available,  
but not that it is for sure the very best available option at this  
instant.

To clarify the point, if I have the option of a route from Canberra  
to Singapore directly (order of 100 ms ping rtt) and a similar route  
via the US west coast (order of 600 ms ping rtt), for a list of  
reasons one really wants the first one. If the choices are among  
three routes sporting ping rtts of 100..110 ms, 105..115 ms, and  
150..160 ms, one would want to ensure that one is using one of the  
two O(100 ms) routes and not the third. But trying to nail down which  
of the two O(100 ms) routes to use is probably not worth the effort.

On Oct 6, 2005, at 7:15 AM, Jari Arkko wrote:

> Delay is a pretty good metric. I have a feeling that packet
> loss is also an important metric when we are talking about
> wireless interfaces and host multihoming, but I have no
> data to back that up.
>
> I liked your idea of comparing the nominal delay to
> actual delay.
>
> The synthetic coordinates idea from Cedric was a very interesting
> one as well. I'd like to play with that if it became available. But  
> I fear
> that DNS storage etc. is a deployment barrier.
>
> Anyway, I see two bigger issue here. The first one is the division
> of work between IP and transports. If we are sure that we
> can develop a simple scheme that works well, it would make sense
> adding to that to the IP layer. But if we find out later that
> we need to take into account variations in congestion level,
> packet loss, etc., we may find ourselves adding a lot of
> functionality to try to mimic what transports are already
> doing. An approach that does not have this drawback would
> be providing feedback from transports and ULPs to the
> shim6 so that when they say "unacceptable", Shim6 would
> attempt to find another path. This would still leave the
> problem of the exploration process finding the right
> alternative with a high probability of success. I'm not sure
> we know how to do that. For instance, if the transports say
> that while the current path works its too small bandwidth,
> we test another one, switch to that, and then find out that
> also is too small. Perhaps delay can act as a metric here,
> but I'd prefer to see some experimental results to understand
> how well it works.
>
> The second issue is our ambition level with load balancing
> functionality in Shim6. If the ambition level is so high that
> we try to get the same session over two paths, then this
> impacts transports. But even if the ambition level is
> running different sessions in different paths, we
> would still have to deal with congestion in some manner.
> Ideally, we'd be adding sessions to a path so that
> the existing sessions do not have to slow down.
>
> If the ambition level is choosing the best path,
> then we are in an area where delay could work
> as a metric, I think. Finally, if the ambition level
> is just choosing a path that gets some packets
> through, we have no problems with the measurements.
> However, because many configurations have a
> high-bandwidth preferred path and a low-bandwidth
> backup (e.g. wireless), and returning to the better
> path is a requirement, I think.
>
> --Jari
>

Delivery-date: Thu, 06 Oct 2005 14:20:28 +0000
Date: Thu, 06 Oct 2005 17:20:25 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>,  [email-masked]
Subject: Review of draft-huitema-shim6-ingress-filtering-00.txt

Christian et al,

I have read your draft. It looks good, I don't have
much to add or correct. A few comments and
questions below, however:

Technical:

>   One possible way to achieve this trust is to make sure that the site
>   routers, or possibly the site firewalls, meet a quality level
>   specified by the provider.
>  
>
I believe the quality requirements would like apply more to the
configuration of the devices than the devices themselves.

>   This mechanism requires a change to the caches used in neighbor
>   discovery, specifically the management of a "source exit cache" that
>   associates a specific source address with an exit router, or maybe
>   the combination of a destination address and a source address with an
>   exit router.
>  
>
I may be missing something here, but I thought that the
ND specifications did not cover association of source
addresses with routers. I thought that within a link, you
can send to any router. But apparently I was mistaken,
if I read the above text correctly.  Where is this specified?

Editorial:

>    cosniderable harm.

typo

>    hosts that preffer such route.

typo

>6.  Appendix A: Host based optimization
>
This appendix is in a middle of the document.

>   preliminary tests on this mechanisms seem to indicate that such
>
s/mechanisms/mechanism/

--Jari

Delivery-date: Thu, 06 Oct 2005 14:15:44 +0000
Date: Thu, 06 Oct 2005 17:15:40 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: delay as a metric, aggregation

Delay is a pretty good metric. I have a feeling that packet
loss is also an important metric when we are talking about
wireless interfaces and host multihoming, but I have no
data to back that up.

I liked your idea of comparing the nominal delay to
actual delay.

The synthetic coordinates idea from Cedric was a very interesting
one as well. I'd like to play with that if it became available. But I fear
that DNS storage etc. is a deployment barrier.

Anyway, I see two bigger issue here. The first one is the division
of work between IP and transports. If we are sure that we
can develop a simple scheme that works well, it would make sense
adding to that to the IP layer. But if we find out later that
we need to take into account variations in congestion level,
packet loss, etc., we may find ourselves adding a lot of
functionality to try to mimic what transports are already
doing. An approach that does not have this drawback would
be providing feedback from transports and ULPs to the
shim6 so that when they say "unacceptable", Shim6 would
attempt to find another path. This would still leave the
problem of the exploration process finding the right
alternative with a high probability of success. I'm not sure
we know how to do that. For instance, if the transports say
that while the current path works its too small bandwidth,
we test another one, switch to that, and then find out that
also is too small. Perhaps delay can act as a metric here,
but I'd prefer to see some experimental results to understand
how well it works.

The second issue is our ambition level with load balancing
functionality in Shim6. If the ambition level is so high that
we try to get the same session over two paths, then this
impacts transports. But even if the ambition level is
running different sessions in different paths, we
would still have to deal with congestion in some manner.
Ideally, we'd be adding sessions to a path so that
the existing sessions do not have to slow down.

If the ambition level is choosing the best path,
then we are in an area where delay could work
as a metric, I think. Finally, if the ambition level
is just choosing a path that gets some packets
through, we have no problems with the measurements.
However, because many configurations have a
high-bandwidth preferred path and a low-bandwidth
backup (e.g. wireless), and returning to the better
path is a requirement, I think.

--Jari

Delivery-date: Thu, 06 Oct 2005 14:03:41 +0000
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Fwd: RFC 4177 on Architectural Approaches to Multi-homing for IPv6
Date: Thu, 6 Oct 2005 16:02:54 +0200
To: [email-masked]

FYI.

- kurtis -

Begin forwarded message:

> From: [email-masked]
> Date: l=F6rdag 1 okt 2005 01.28.48 GMT+02:00
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4177 on Architectural Approaches to Multi-homing for IPv6
>
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4177
>
>         Title:      Architectural Approaches to Multi-homing for IPv6
>         Author(s):  G. Huston
>         Status:     Informational
>         Date:       September 2005
>         Mailbox:    [email-masked]
>         Pages:      36
>         Characters: 95374
>         Updates/Obsoletes/SeeAlso:    None
>
>         I-D Tag:    draft-ietf-multi6-architecture-04.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4177.txt
>
>
> This memo provides an analysis of the architectural aspects of
> multi-homing support for the IPv6 protocol suite.  The purpose of
> this analysis is to provide a taxonomy for classification of various
> proposed approaches to multi-homing.  It is also an objective of
> this exercise to identify common aspects of this domain of study, and
> also to provide a framework that can allow exploration of some of the
> further implications of various architectural extensions that are
> intended to support multi-homing.
>
> This document is a product of the Site Multihoming in IPv6 Working
> Group of the IETF.
>
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  =20
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions =20
> to RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

Delivery-date: Thu, 06 Oct 2005 08:37:11 +0000
Cc: "shim6" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-proto-00.txt
Date: Thu, 6 Oct 2005 10:37:25 +0200
To: "Spencer Dawkins" <[email-masked]>

Hi Spencer,

El 05/10/2005, a las 19:27, Spencer Dawkins escribi=F3:

>> Another missing discussion: the document refers to
>> SCTP as if it would be obvious how it can use Shim6. I'm
>> not sure that's the case. Or at least its not obvious to me :-)
>
> Just a minor point here - I'm assuming that SCTP would work over Shim6=20=

> if an SCTP implementation was Shim6-unaware; the "IPv6 addresses"=20
> included in SCTP Init and Init-ACK chunks would work even if a Shim6=20=

> added locators for these identifiers "under the covers".
>
> I've been seeing references to "turning Shim6 OFF for SCTP", since=20
> SCTP is capable of handling its own multihoming, but I don't think=20
> anything is particularly BROKEN if SCTP is naively using identifiers=20=

> as if they were locators. My understanding is that we're talking about=20=

> efficiency, not correct operation, when we talk about Shim6 and SCTP=20=

> in this context.
>

I have the same understanding about how this should work.

I guess the point is that we have to make sure that this is so, and for=20=

this we need to analyze in detail how this shim-sctp interaction would=20=

be. For that we need shim and sctp expertise but from what i have seen=20=

i think there are many folks involved in sctp around, so i would expect=20=

that this analysis is properly performed

regards, marcelo

> As Jari pointed out, Shim6 is closely tied to IPv6, but I note that=20
> SCTP supports both IPv4 and IPv6 multihoming - this could be an=20
> incentive to use SCTP instead of Shim6 for multihoming (if both are=20
> available, and if there's a knob to "turn Shim6 OFF for SCTP").
>
> Do others have a different understanding?
>

> Spencer
>

Delivery-date: Wed, 05 Oct 2005 18:47:19 +0000
Date: Wed, 05 Oct 2005 11:46:15 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

> The proxy wouldn't pick addresses, it would only map prefixes. So the 
> end-host inside the shimmed area could use a CGA address (thanks btw for 
> helping me to prod my brain into grokking them offline ;) ). Ie:
> 
> host uses: <prefix>:<CGA interface identifier>

But how is the host told to use that interface ID?
Manual config?
DHCPv6?

If the host uses stateless autoconfig or temporary ("privacy") addresses 
they sure will not have that interface ID.

> Why wouldn't it be exactly? Publishing something in DNS is no guarantee 
> of reachability. It would be /intended/ to be reachable, via shim6.
> 
> The taboo was on non-globally-unique addresses in DNS, i thought?

There has been a fair amount of discussion in DNSOP WG what to recommend 
or not in this space, but no consensus AFAIK.

If you publish an unreachable some applications will take a long time to 
connect (they might end up trying the unreachable first, and when TCP 
fails to connect fallback to the next in the list.) Other applications 
might only try the first address returned by gethostbyname/getaddrinfo.

Such applications are not much good in terms of failover for multihomed 
hosts, but they are the current legacy, and it might be a bad idea to 
make them work worse then they do today.

>> Even if folks agree on that, the fact that the internal hosts would 
>> see both the local/internal address, and the shimmed addresses, would 
>> mean that they might seeming randomly end up using the shimmed 
>> addresses, and such internal communication ends up going via the proxy.
> 
> 
> Not sure why that'd be so. It's an interior routing issue.

I don't understand. The hosts select which source/dest combinations to 
try first. The recommendation for how to do this in RFC 3484.
Once the host has decided, the routing system gets to forward that TCP 
SYN (or whatever it is) to the destination IP address.

    Erik

Delivery-date: Wed, 05 Oct 2005 17:44:27 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "shim6-wg" <[email-masked]>
Cc: "Mark Allman" <[email-masked]>
Subject: [Semi-OT] Transport resistance to reordering
Date: Wed, 5 Oct 2005 12:43:33 -0500

We've had a few conversations about load-spreading that assumed TCP (and 
related transports) would respond badly to significant levels of reordering 
(they respond badly today).

I was chatting about this with Mark Allman, who pointed me towards 
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-05.txt.

I don't think this is ON topic for Shim6, but if people are interested, it's 
on-topic for tcpm (http://www.ietf.org/html.charters/tcpm-charter.html).

(Since IP stacks have to be updated for Shim6 anyway...)

Thanks,

Spencer 

Delivery-date: Wed, 05 Oct 2005 17:28:39 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "shim6" <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-proto-00.txt
Date: Wed, 5 Oct 2005 12:27:31 -0500

> Another missing discussion: the document refers to
> SCTP as if it would be obvious how it can use Shim6. I'm
> not sure that's the case. Or at least its not obvious to me :-)

Just a minor point here - I'm assuming that SCTP would work over Shim6 if an 
SCTP implementation was Shim6-unaware; the "IPv6 addresses" included in SCTP 
Init and Init-ACK chunks would work even if a Shim6 added locators for these 
identifiers "under the covers".

I've been seeing references to "turning Shim6 OFF for SCTP", since SCTP is 
capable of handling its own multihoming, but I don't think anything is 
particularly BROKEN if SCTP is naively using identifiers as if they were 
locators. My understanding is that we're talking about efficiency, not 
correct operation, when we talk about Shim6 and SCTP in this context.

As Jari pointed out, Shim6 is closely tied to IPv6, but I note that SCTP 
supports both IPv4 and IPv6 multihoming - this could be an incentive to use 
SCTP instead of Shim6 for multihoming (if both are available, and if there's 
a knob to "turn Shim6 OFF for SCTP").

Do others have a different understanding?

Spencer 

Delivery-date: Wed, 05 Oct 2005 14:05:58 +0000
Date: Wed, 05 Oct 2005 17:05:18 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-proto-00.txt

marcelo bagnulo braun wrote:

>> Yet another missing discussion: is there some interaction
>> with this protocol and the protocol defined in Marcelo's
>> draft that talked about communication with non-shim6
>> peers? It would appear that some aspects (e.g. input from
>> RAs) is common.
>
>
> As i understand it, we have two cases:
> - a host within the multihomed site that wants to initiate a new 
> communication with an external legacy host after an outage, and
> - a host within the multihomed site that wants to initiate a new 
> communication with an external shim host after an outage
>
> In the first case the mechanisms for doing this must only reside in 
> the multihomed host, while in the second case, the mechanism can 
> involve both (the multihomed and the external) hosts
>
> Clearly the mechanisms used for the first case can be used for the 
> second case as well (obviously the mechanisms for the second and not 
> suitable for the first case)
>
> The question is whether it wouldn't be better to define mechanisms 
> that are specific for the second case, taking advantage of the shim 
> capabilities of the shim peer.
>
> The benefit that i can think of in this case would be that retrial 
> would be transparent for the ULP, since it would be solved by the shim.
> The drawback is that the shim session needs to be established before 
> the communication is initiated, which may not always be the case. An 
> additional drawback is the added complexity, that need to quantify, 
> since these shim based mechanisms to deal with non working ULIDs are 
> in addition to the mechanisms for dealing with legacy hosts. 
> Additional difficulties for this mechanisms is the discovery of 
> alternative locators for initiating the communication, which is likely 
> to be based on information posted in the DNS, but that information is 
> probably not as good as it may seem, since the addresses associated 
> with a given FQDN may not belong to a single host, resulting in 
> invalid ULID/locator combinations.
>
> As a side note, these mechanisms for dealing with non reachable ULIDs 
> are needed for supporting things like ULAs as ULIDs.

As I see it, your draft actually had two parts: what to do and how
to find out what prefix isn't working right now. The latter part
provides information that the shim6 protocol should also use.
As you note above, the former part has some tradeoffs and needs
more discussion.

>>
>>>   multihoming can be provided for IPv6 with failover and load spreading
>>>   properties
>>>
>> I'm a bit concerned that we have not figured out all the details
>> regarding load spreading. You don't want a particular session
>> spread around different paths, because doing so would
>> confuse existing congestion avoidance mechanisms. The obvious
>> answer appears to be making sure that that we keep the same
>> locator pair for the same session. But can we identify sessions
>> in all cases? Also, protocol description in Section 4 and beyond
>> does not talk about when and how loadsharing is initiated and
>> abandoned.
>>
>
> I am not sure what do you mean by load sharing...

I mean to say "load spreading" which was the term the
document used. But no matter what the term is, my
point was that we have not defined what this means in
detail. As you note below there are some different
possibilities.

> If we are talking about distributing the traffic across the multiple 
> exit paths of the multihomed site, i would say that this would be 
> naturally provided by the selection of ULIDs by the applications. I 
> mean, just the fact that different hosts select different prefixes for 
> initiating communications would result in a distribution of the load 
> across the different ISPs.
> I mean that there is no point to distribute the packets of a given 
> communication among the different paths, since what really matters 
> AFAICT is the overall load, which is the aggregation of the load of 
> all nodes, which will be distributed because different communications 
> will use different prefixes hence different ISPs (as opposed to a 
> single communication distributing the load among multiple ISPs)
>
> However, this is clearly not good enough for achieving some form of 
> traffic engineering or policing where something more that spreading 
> the load evenly across isps is required.
>
> In any case, i think it would make sense to explain this in the doc
>
>>>   In addition, the non-shim6 messages, which we call payload packets,
>>>   will not contain the ULIDs after a failure.  This introduces the
>>>   requirement that the <peer locator, local locator, local context tag>
>>>   MUST uniquely identify the context.  Since the peer's set of locators
>>>   might be dynamic the simplest form of unique allocation of the local
>>>   context tag is to pick a number that is unique on the host.  Hosts
>>>   which serve multiple ULIDs using disjoint sets of locators can
>>>   maintain the context tag allocation per such disjoint set.
>>>
>> Not sure if this always needs to be true.
>> It might be that the shim6 failover protocol signaling
>> is used to tell the peer what the new locators are. If
>> that's the case, then the local context tag alone does
>> not need to be unique, you could rely also on the
>> addresses.
>>
>> Also, there seems to be security issue in using just
>> the context tag to do the demux.
>
>
> as i understand it, once that the context is identified using the 
> context tag, the addresses included in the packet are verified against 
> the locator set available for that context. If the addresses included 
> in the packet are not included in the locator set of the context, the 
> packet will be ignored

Ok. This would work. Maybe I missed that statement if it was in
the document.

>> It might be possible to combine these functions. But lets
>> do the individual design first for each, and combine later
>> if possible.
>>
>> Also, the assistance from payload packets in the explore
>> phase is not discussed.
>
>
> i am missing what you mean here... could you expand?

This is what we had discussed earlier, I think on Christian's
suggestion, that the reception of payload packets with
a specific src/dst could be used as assistance in the
exploration phase.

--Jari

Delivery-date: Wed, 05 Oct 2005 13:41:37 +0000
Cc: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Comments on draft-ietf-shim6-proto-00.txt
Date: Wed, 5 Oct 2005 15:41:51 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

my p.o.v. w.r.t. the comments you made
El 05/10/2005, a las 14:29, Jari Arkko escribi=F3:

>
> Hi Erik,
>
> Thanks for writing this. We are beginning to see
> a complete shim6 protocol proposal! This document
> answered many questions that I have had at least.
> Overall, I think the approach is solid. But I did have
> a number of questions and comments, see below:
>
> Technical:
>
> Missing a discussion on the relationship of the shim6
> processing wrt other processing that is taking place
> at the IP layer, including at least IPsec but probably
> also Mobile IPv6. I know from past experience that
> its quite hard to define the relationships and processing
> order correctly, and I suspect that its increasingly hard
> for shim6.
>
> Also, what is the relationship of Shim6 processing to
> things in the host that depend on literal addresses,
> such as IPsec policies?
>
> Another missing discussion: the document refers to
> SCTP as if it would be obvious how it can use Shim6. I'm
> not sure that's the case. Or at least its not obvious to me :-)
>

basically, as i read it, the point would be to include a section about=20=

shim interaction with other potentially affected protocols, such as=20
MIP, IPSec, SCTP

I think this makes sense

> Yet another missing discussion: is there some interaction
> with this protocol and the protocol defined in Marcelo's
> draft that talked about communication with non-shim6
> peers? It would appear that some aspects (e.g. input from
> RAs) is common.

As i understand it, we have two cases:
- a host within the multihomed site that wants to initiate a new=20
communication with an external legacy host after an outage, and
- a host within the multihomed site that wants to initiate a new=20
communication with an external shim host after an outage

In the first case the mechanisms for doing this must only reside in the=20=

multihomed host, while in the second case, the mechanism can involve=20
both (the multihomed and the external) hosts

Clearly the mechanisms used for the first case can be used for the=20
second case as well (obviously the mechanisms for the second and not=20
suitable for the first case)

The question is whether it wouldn't be better to define mechanisms that=20=

are specific for the second case, taking advantage of the shim=20
capabilities of the shim peer.

The benefit that i can think of in this case would be that retrial=20
would be transparent for the ULP, since it would be solved by the shim.
The drawback is that the shim session needs to be established before=20
the communication is initiated, which may not always be the case. An=20
additional drawback is the added complexity, that need to quantify,=20
since these shim based mechanisms to deal with non working ULIDs are in=20=

addition to the mechanisms for dealing with legacy hosts. Additional=20
difficulties for this mechanisms is the discovery of alternative=20
locators for initiating the communication, which is likely to be based=20=

on information posted in the DNS, but that information is probably not=20=

as good as it may seem, since the addresses associated with a given=20
FQDN may not belong to a single host, resulting in invalid ULID/locator=20=

combinations.

As a side note, these mechanisms for dealing with non reachable ULIDs=20
are needed for supporting things like ULAs as ULIDs.

>
> And one more: the document is relatively silent on
> (un)reachability detection mechanisms beyond shim6-based
> probing. We do have ND(NUD), L2, etc. mechanisms that
> should be taken into account. If your L2 tells you that its
> lost the connection, there's no point in probing at L3,
> we need to find another interface!
>
>>   multihoming can be provided for IPv6 with failover and load=20
>> spreading
>>   properties
>>
> I'm a bit concerned that we have not figured out all the details
> regarding load spreading. You don't want a particular session
> spread around different paths, because doing so would
> confuse existing congestion avoidance mechanisms. The obvious
> answer appears to be making sure that that we keep the same
> locator pair for the same session. But can we identify sessions
> in all cases? Also, protocol description in Section 4 and beyond
> does not talk about when and how loadsharing is initiated and
> abandoned.
>

I am not sure what do you mean by load sharing...
If we are talking about distributing the traffic across the multiple=20
exit paths of the multihomed site, i would say that this would be=20
naturally provided by the selection of ULIDs by the applications. I=20
mean, just the fact that different hosts select different prefixes for=20=

initiating communications would result in a distribution of the load=20
across the different ISPs.
I mean that there is no point to distribute the packets of a given=20
communication among the different paths, since what really matters=20
AFAICT is the overall load, which is the aggregation of the load of all=20=

nodes, which will be distributed because different communications will=20=

use different prefixes hence different ISPs (as opposed to a single=20
communication distributing the load among multiple ISPs)

However, this is clearly not good enough for achieving some form of=20
traffic engineering or policing where something more that spreading the=20=

load evenly across isps is required.

In any case, i think it would make sense to explain this in the doc

>>   o  Communication continues without any change for the ULP packets.
>>      In addition, there might be some messages exchanged between the
>>      shim sub-layers for (un)reachability detection.
>>
>>   o  At some point in time something fails.  Depending on the =
approach
>>      to reachability detection, there might be some advise from the
>>      ULP, or the shim (un)reachability detection might discover that
>>      there is a problem.
>>
>>      At this point in time one or both ends of the communication need
>>      to explore the different alternate locator pairs until a working
>>      pair is found, and rehome to using that pair.
>>
> Some additional thinking may be needed here wrt. what
> goes on in the alternative paths during the first step and
> which end does what in the second step.The reason that
> I worry about this is the various middleboxes that we may
> have.
>
> In an IPv6-only world we don't need to worry about NATs.
> However, there may be stateful firewalls that prevent, for
> instance, the peer from contacting our other locator since
> the firewall may not have seen any traffic to the peer from
> our other locator yet.

>
>>   o  The shim (un)reachability detection will monitor the new locator
>>      pair as it monitored the original locator pair, so that=20
>> subsequent
>>      failures can be detected.
>>
> There's no consideration here for switch-due-to-policy, such as
> someone preferring his LAN connection when its present
> over wireless connections, regardless of whether the wireless
> works or not. Personally, I'm fine with avoiding
> policy (it'll never get configured anyway) but perhaps this
> is a limitation that should be explicitly stated & discussed.
>

i think it may be good to support this configuration...

I mean, this would be also the case of primary/backup configuration=20
where the backup link has worse performance than the primary, so the=20
primary is preferred as soon as it is available

> This is also related to the load sharing support.
>
>>   For commonly
>>   used IP protocols this is done by using a different value in the=20
>> Flow
>>   Label field, that is, there is no additional header added to the
>>   packets.  But for other IP protocol types there is an extra 8 byte
>>   header inserted, which carries the next header value.
>>
> This seems a bit surprising, but I'm probably missing
> something. (Postscript: after reading the rest of the
> document I now understand what's going on. But there
> may be other readers who are left wondering at this
> point in the document.)
>
>>   In addition, the non-shim6 messages, which we call payload packets,
>>   will not contain the ULIDs after a failure.  This introduces the
>>   requirement that the <peer locator, local locator, local context=20
>> tag>
>>   MUST uniquely identify the context.  Since the peer's set of=20
>> locators
>>   might be dynamic the simplest form of unique allocation of the =
local
>>   context tag is to pick a number that is unique on the host.  Hosts
>>   which serve multiple ULIDs using disjoint sets of locators can
>>   maintain the context tag allocation per such disjoint set.
>>
> Not sure if this always needs to be true.
> It might be that the shim6 failover protocol signaling
> is used to tell the peer what the new locators are. If
> that's the case, then the local context tag alone does
> not need to be unique, you could rely also on the
> addresses.
>
> Also, there seems to be security issue in using just
> the context tag to do the demux.

as i understand it, once that the context is identified using the=20
context tag, the addresses included in the packet are verified against=20=

the locator set available for that context. If the addresses included=20
in the packet are not included in the locator set of the context, the=20
packet will be ignored

As i see it the unique context tag is needed not because we have=20
unknown addresses than can be used as locators, but because those=20
addresses may be inlcuded in more than one context.
So if both contextA and contextB have Address1 and Address2 as valid=20
locators (for each endpoint) then when a packet using Address! and=20
Adress2 is received, the hosts cannot tell which context (A or B) to=20
use to perform the demux

Both Address1 and Address2 must have been validated and are included=20
explicitly as locators in the locators set of each context.

>  (Or is there some
> crypto hash somewhere too?) If I learn or guess
> your tag, does that mean that I can start sending
> traffic that appears to come from you, even if I
> use a different source IP and my host is under
> ingress filtering restrictions?
>

i don't think so, see above

>>
....
>
>>   The peers' lists of locators are normally exchanged as part of the
>>   context establishment exchange.  But the set of locators might be
>>   dynamic.  For this reason there is a Locator List Update message =
and
>>   acknowledgement.
>>
> This appears to require (optional?) CGA.

right

>  Perhaps this could be stated
> earlier on when you talked about HBA.
>
>>   The above probe and keepalive messages assume we have an =
established
>>   host-pair context.  However, communication might fail during the
>>   initial context (that is, when the application or transport =
protocol
>>   is trying to setup some communication).  If we want the shim to be
>>   able to optimize discovering a working locator pair in that case, =
we
>>   need a mechanism to test the reachability of locators independent =
of
>>   some context.  We define a locator pair test message and
>>   acknowledgement for this purpose, even though it isn't yet clear
>>   whether we need such a thing.
>>
> It isn't clear to me how this would be done. Presumably
> its the application that is going through the IPs retrieved
> from DNS, not the IP layer.

right

>  Is this something that we
> need to handle?
>

i guess that is under discussion if it is worthy, see above...

....
> It might be possible to combine these functions. But lets
> do the individual design first for each, and combine later
> if possible.
>
> Also, the assistance from payload packets in the explore
> phase is not discussed.

i am missing what you mean here... could you expand?

regards, marcelo

Delivery-date: Wed, 05 Oct 2005 12:30:10 +0000
Date: Wed, 05 Oct 2005 15:29:17 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Comments on draft-ietf-shim6-proto-00.txt

Hi Erik,

Thanks for writing this. We are beginning to see
a complete shim6 protocol proposal! This document
answered many questions that I have had at least.
Overall, I think the approach is solid. But I did have
a number of questions and comments, see below:

Technical:

Missing a discussion on the relationship of the shim6
processing wrt other processing that is taking place
at the IP layer, including at least IPsec but probably
also Mobile IPv6. I know from past experience that
its quite hard to define the relationships and processing
order correctly, and I suspect that its increasingly hard
for shim6.

Also, what is the relationship of Shim6 processing to
things in the host that depend on literal addresses,
such as IPsec policies?

Another missing discussion: the document refers to
SCTP as if it would be obvious how it can use Shim6. I'm
not sure that's the case. Or at least its not obvious to me :-)

Yet another missing discussion: is there some interaction
with this protocol and the protocol defined in Marcelo's
draft that talked about communication with non-shim6
peers? It would appear that some aspects (e.g. input from
RAs) is common.

And one more: the document is relatively silent on
(un)reachability detection mechanisms beyond shim6-based
probing. We do have ND(NUD), L2, etc. mechanisms that
should be taken into account. If your L2 tells you that its
lost the connection, there's no point in probing at L3,
we need to find another interface!

>   multihoming can be provided for IPv6 with failover and load spreading
>   properties
>
I'm a bit concerned that we have not figured out all the details
regarding load spreading. You don't want a particular session
spread around different paths, because doing so would
confuse existing congestion avoidance mechanisms. The obvious
answer appears to be making sure that that we keep the same
locator pair for the same session. But can we identify sessions
in all cases? Also, protocol description in Section 4 and beyond
does not talk about when and how loadsharing is initiated and
abandoned.

>   o  Communication continues without any change for the ULP packets.
>      In addition, there might be some messages exchanged between the
>      shim sub-layers for (un)reachability detection.
>
>   o  At some point in time something fails.  Depending on the approach
>      to reachability detection, there might be some advise from the
>      ULP, or the shim (un)reachability detection might discover that
>      there is a problem.
>
>      At this point in time one or both ends of the communication need
>      to explore the different alternate locator pairs until a working
>      pair is found, and rehome to using that pair.
>  
>
Some additional thinking may be needed here wrt. what
goes on in the alternative paths during the first step and
which end does what in the second step. The reason that
I worry about this is the various middleboxes that we may
have.

In an IPv6-only world we don't need to worry about NATs.
However, there may be stateful firewalls that prevent, for
instance, the peer from contacting our other locator since
the firewall may not have seen any traffic to the peer from
our other locator yet.

>   o  The shim (un)reachability detection will monitor the new locator
>      pair as it monitored the original locator pair, so that subsequent
>      failures can be detected.
>  
>
There's no consideration here for switch-due-to-policy, such as
someone preferring his LAN connection when its present
over wireless connections, regardless of whether the wireless
works or not. Personally, I'm fine with avoiding
policy (it'll never get configured anyway) but perhaps this
is a limitation that should be explicitly stated & discussed.

This is also related to the load sharing support.

>   For commonly
>   used IP protocols this is done by using a different value in the Flow
>   Label field, that is, there is no additional header added to the
>   packets.  But for other IP protocol types there is an extra 8 byte
>   header inserted, which carries the next header value.
>
This seems a bit surprising, but I'm probably missing
something. (Postscript: after reading the rest of the
document I now understand what's going on. But there
may be other readers who are left wondering at this
point in the document.)

>   In addition, the non-shim6 messages, which we call payload packets,
>   will not contain the ULIDs after a failure.  This introduces the
>   requirement that the <peer locator, local locator, local context tag>
>   MUST uniquely identify the context.  Since the peer's set of locators
>   might be dynamic the simplest form of unique allocation of the local
>   context tag is to pick a number that is unique on the host.  Hosts
>   which serve multiple ULIDs using disjoint sets of locators can
>   maintain the context tag allocation per such disjoint set.
>  
>
Not sure if this always needs to be true.
It might be that the shim6 failover protocol signaling
is used to tell the peer what the new locators are. If
that's the case, then the local context tag alone does
not need to be unique, you could rely also on the
addresses.

Also, there seems to be security issue in using just
the context tag to do the demux. (Or is there some
crypto hash somewhere too?) If I learn or guess
your tag, does that mean that I can start sending
traffic that appears to come from you, even if I
use a different source IP and my host is under
ingress filtering restrictions?

>   Whether we overload the flow label field to carry the context tag or
>   not, any protocol (such as RSVP or NSIS) which signals information
>   about flows from the host stack to devices in the path, need to be
>   made aware of the locator agility introduced by a layer 3 shim, so
>   that the signaling can be performed for the locator pairs that are
>   currently being used.
>  
>
I'd like to understand this better. Is the information flow
always from the host to the middleboxes and routers?
If yes, then the host can keep its choices about the flow
labels. If not, then we may have a problem.

>4.2  Protocol type overloading
>
>   The mechanism for detecting a loss of context state at the peer that
>   is currently proposed in this document assumes that the receiver can
>   tell the packets that need locator rewriting, even after it has lost
>   all state (e.g., due to a crash followed by a reboot).  There is an
>   alternative to detection of lost state outlined in Section 18.
>
>   The idea is to steal a partial bit from the protocol type fields that
>   are used in the Next Header values, so that the common upper layer
>   protocols can be identified.
>
>   For example:
>
>   o  TCP has protocol 6; TCP using alternate locators has protocol P.
>  
>
In a crash followed by reboot it does not help that shim6
recovers the state. TCP and SCTP state is gone anyway.
For UDP and ICMP shim6 recovery would help.

However, there may be other conditions, such as loss
of state due to premature garbage collection which makes
all this necessary. Perhaps you could just use a different
example above. Or would synchronized state removal
be an option?

>   Thus with 7 or so additional protocol field values we can do a
>   reasonable job of overloading the flow label field and get detection
>   of lost context state.
>  
>
This is primarily an optimization. I wonder if it would make
sense to limit the optimization to the 80% useful case which
to me would be TCP, ESP, UDP, or even less. No sense in
optimization ICMP messages, I think.

>   The peers' lists of locators are normally exchanged as part of the
>   context establishment exchange.  But the set of locators might be
>   dynamic.  For this reason there is a Locator List Update message and
>   acknowledgement.
>  
>
This appears to require (optional?) CGA. Perhaps this could be stated
earlier on when you talked about HBA.

>   The above probe and keepalive messages assume we have an established
>   host-pair context.  However, communication might fail during the
>   initial context (that is, when the application or transport protocol
>   is trying to setup some communication).  If we want the shim to be
>   able to optimize discovering a working locator pair in that case, we
>   need a mechanism to test the reachability of locators independent of
>   some context.  We define a locator pair test message and
>   acknowledgement for this purpose, even though it isn't yet clear
>   whether we need such a thing.
>  
>
It isn't clear to me how this would be done. Presumably
its the application that is going through the IPs retrieved
from DNS, not the IP layer. Is this something that we
need to handle?

>   o  The CGA PDS might not need to be included in every LLU message.
>      If it is associated with the ULID, it is sufficient to exchange it
>      once.  Then a HBA-protected LLU would not need anything (it can
>      just change the preferences for the locators in any case), and a
>      CGA-protected LLU would just need the signature option.
>  
>
Right. Lets make it so :-)

>  |            |                                                     |
>  |     10     |                  Reachability Probe                 |
>  |            |                                                     |
>  |     11     |               Reachability Probe Reply              |
>  |            |                                                     |
>  |     13     |                      Keepalive                      |
>  |            |                                                     |
>  |     14     |                  Locator Pair Test                  |
>  |            |                                                     |
>  |     15     |               Locator Pair Test Reply               |
>  |            |                                                     |
>  |     16     |             Context Locator pair explore            |
>  +------------+-----------------------------------------------------+
>  
>
It might be possible to combine these functions. But lets
do the individual design first for each, and combine later
if possible.

Also, the assistance from payload packets in the explore
phase is not discussed.

Finally, I hope everyone is OK with the design that is
extremely tightly integrated with IPv6. I know its
in our charter, but I still worry about it since I see
so many things that eventually had to work on both
v6 and v4 (people working on mobile IP now to run on both,
IPsec has done so for a very long time, IP multimedia
systems had to run on v4 too, etc). We won't be able
to do this for Shim6.

Editorial:

>       different path through the Internt, hence the path MTU might be

typo

>    o  Applications that perform referals, or callbacks using IP

s/referals/referrals/g

>    the reponder can verify that the validator it receives back in the I2

typo

>    11.  Taredown of the Host Pair Context  . . . . . . . . . . . . .  43

s/taredown/teardown/g

>   There is a No Contex error message defined, when a control or payload
>
s/Contex/Context/g

--Jari

Delivery-date: Wed, 05 Oct 2005 09:29:19 +0000
Date: Wed, 05 Oct 2005 12:29:20 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: Comments on draft-bagnulo-shim6-addr-selection-00.txt

marcelo bagnulo braun wrote:

> well, dhcp6 does have a push option AFAIU, which means that the dhcp 
> server could actually push the changes on the policyt table to the 
> hosts when a change is needed. I guess that this would deal with 
> dynamic outages.

Ok. I didn't know that.

--Jari

Delivery-date: Wed, 05 Oct 2005 09:12:00 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Comments on draft-bagnulo-shim6-addr-selection-00.txt
Date: Wed, 5 Oct 2005 11:12:30 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

thanks for the reading and commenting the draft...

El 05/10/2005, a las 8:44, Jari Arkko escribi=F3:
>
>> 5.1.1.  Direct link failures
>>
> The title seems a bit misleading. I thought first that
> you were talking about the direct link from the host,
> but this was really the link from the local router to the
> ISP.
>

right

> Anyway, I think you are missing a discussion of the
> first case. Here it may even be that existing mechanisms
> already solve the problem, because presumably RFC 3484
> would not select source addresses from a link that's down.
> But it would still be important to note this.
>

right, i will add some comments about this

>>   The missing part is a mechanism to convey the information from the
>>   server to the host.  A possible option is to define a new DHCP=20
>> option
>>   to transmit policy table information.
>>
> This does not appear to be able to deal with dynamic
> outages, or does it? At the very least the lease times
> would have to be set low.

well, dhcp6 does have a push option AFAIU, which means that the dhcp=20
server could actually push the changes on the policyt table to the=20
hosts when a change is needed. I guess that this would deal with=20
dynamic outages.

>
>>   It is also possible to enable the multihomed host to query the=20
>> server
>>   to obtain the source address prefix information as proposed in [6] =
.
>>   In this case, each time the multihomed node initiates a=20
>> communication
>>   with a new destiantion, it would query the server for the proper
>>   prefix to include in the source address.  The server, would reply
>>   based on the routing information it has gathered through BGP.
>>
> This might be a better alternative, perhaps modified by
> only doing the query if you can't establish a connection.

well, as i recall the naros idea, was to also allow some traffic=20
engineering possibilities, which is why querying each time may make=20
sense. OTOH, this does introduce some overhead, so, omitting it as you=20=

suggest makes also sense

>
>>   The first option is to simply let the upper layers to handle
>>   retrials.  In this case, the IP layer only has to make sure that a
>>   different source address is used in each retrial as long as there =
is
>>   not a preferred source address in the source address cache.  So, in
>>   this approach, when the IP layer receives a packet, it searches the
>>   Source Address Cache for a preferred source address associated to=20=

>> the
>>   selected destination.  If no entry exists for that destination
>>   address, one of the available source addresses is selected =
randomly.
>>   If reply packets arrive, an entry will be created in the Source
>>   Address Cache for that destination address.  If no reply packets
>>   arrive, no entry will be created, so when the upper layer protocol
>>   resends the packet, a new source address will be used.
>>
> I may be confused here, but I suppose you are not talking
> about IP packets, you are talking about connection initiation.

Well, actually i am talking about every time that the address selection=20=

mechanism (RFC 3484) is performed.
This includes the moment that a TCP connection is initiated (as you=20
mention) but also each time an UDP packet is sent i guess. It does not=20=

includes subsequent packets once that a TCP connection is initiated,=20
since selected addresses are used, as you point out.

I will add more detail explaining this clearly.

Thanks, marcelo

> You can't change source address on the fly from an existing
> TCP sessions.
>
> --Jari
>

Delivery-date: Wed, 05 Oct 2005 08:20:27 +0000
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Agenda for interim meeting
Date: Wed, 5 Oct 2005 10:21:16 +0200
To: shim6-wg <[email-masked]>

Please forget this message, i got confused

sorry for the noise

regards, marcelo

El 05/10/2005, a las 9:54, marcelo bagnulo braun escribi=F3:

> Do we have an agenda for the interim meeting?
>
> thanks, marcelo
>
>

Delivery-date: Wed, 05 Oct 2005 08:18:22 +0000
Cc: shim6-wg <[email-masked]>, John Payne <[email-masked]>, David Meyer <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
Date: Wed, 5 Oct 2005 10:18:54 +0200
To: "Jason Schiller ([email-masked])" <[email-masked]>

Hi Jason,

limited the cc list to the shim...

[Note : FWIW i think that the feedback from the ISP community is very=20
valuable, so this is not the point that i am discussing here]

El 04/10/2005, a las 21:54, Jason Schiller ([email-masked]) escribi=F3:

>
> On Tue, 4 Oct 2005, John Payne wrote:
>
>> Date: Tue, 04 Oct 2005 14:10:27 -0400
>> From: John Payne <[email-masked]>
>> To: Iljitsch van Beijnum <[email-masked]>
>> Cc: David Meyer <[email-masked]>, [email-masked], [email-masked],=20
>> [email-masked]
>> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
>>
>>
>> On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote:
>>
>>> NANOG =3D network operators in the sense of ISPs and the like. The
>>> solution that the shim6 is working on does NOT apply to this
>>> demographic.
>>
>> Whoa there.  The NANOG community (as well as other ISP communities) =
is
>> hugely affected by shim6.
>>
>> They are the ones who will be fielding customer calls about=20
>> multihoming
>> - "why can't I just setup BGP like I always have done?".  Not =
everyone
>> at NANOG is going to be big enough to get a /32, but most of the ISPs
>> there are at least multihomed today.
>
>>> I urge the discussion leaders to make it painfully clear to which
>>> types of users the shim6 solution space applies and to which type of
>>> users it doesn't.
>
> Doesn't this apply to any orgization that doesn't have its own /32?
>

well, i have always read the term site multihoming as kind of opposed=20
to two other concepts: host multihoming and ISP multihoming

So i would say that the design goal of the shim is focus in the support=20=

end-site multihoming support rather than ISP multihoming

For instance, i read the goals described in RFC 3582 are more the goals=20=

of an end-site rather than the goals of an ISP (probably the goals of=20
an ISP would a superset of the goals of an end-site imho.) In=20
particular, there are no references in that document in the impact of =20=

the solution in clients of the ISP (i don't know, but i guess that=20
there should some considerations about that when considering ISP=20
multihoming)
Other assumption that may or not have impact, is that an end site seems=20=

to assume that there is a single administrative domain rather than an=20
ISP with multiple customers where there are many administrative=20
domains.

Perhaps a good question (at least for me) would be if you think that=20
the goals expressed in RFC 3582 properly describe the goals for ISP=20
multihoming or if you think that something is missing there

since those are the goals the the shim is trying to reach, this may=20
explain what is to be expected from it.

Regards, marcelo

> Doesn't this apply to any orgization that has customers that require
> multihoming but lack their own /32 as John points out?
>
> Doesn't this apply to any orgization that has it's own IPv6 aggregate,
> and wants to advertise something more specific than its aggregate?
>
> If that is the case, then it won't just apply to ISPs or multi-homed=20=

> end
> sites who can't get a /32, it also applies to ISPs and end sites who=20=

> have
> a /32, but need to split route announcement to share load across=20
> multiple
> transit providers.
>
> ___Jason
>
>

Delivery-date: Wed, 05 Oct 2005 07:53:38 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Agenda for interim meeting
Date: Wed, 5 Oct 2005 09:54:00 +0200

Do we have an agenda for the interim meeting?

thanks, marcelo

Delivery-date: Wed, 05 Oct 2005 06:49:36 +0000
Date: Wed, 05 Oct 2005 16:48:37 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Call for agenda items for IETF 65

Hi,

         We've asked the secretariat to schedule a 2.5 hour
         session for IETF65. Well be reviewing work on the current
         active drafts, as part of the agenda, and we are interested
         to hear of any other relevant agenda items that folk want to
         talk about. Please forward any proposed
         agenda topics to Geoff ([email-masked]) and Kurtis
         ([email-masked]) and let us know as well:

         (i).    The topic you'll be presenting on

         (ii).   How much time you require
                  (c'mon - be real - 5 minutes doesn't even get
                   past the title slide!)

         (iii).  Which draft you will be talking about. If there
                 is no draft, please describe how the talk relates
                 to the goals and charter of SHIM6.

         (iv).   Name of person (or persons) giving the presentation

thanks,

  Kurtis and Geoff

Delivery-date: Wed, 05 Oct 2005 06:44:45 +0000
Date: Wed, 05 Oct 2005 09:44:16 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Comments on draft-bagnulo-shim6-addr-selection-00.txt

Hi Marcelo,

And thanks for writing this draft. This is an important
scenario to cover. Generally speaking I like your
solutions. A few comments, however:

>5.1.1.  Direct link failures
>
The title seems a bit misleading. I thought first that
you were talking about the direct link from the host,
but this was really the link from the local router to the
ISP.

Anyway, I think you are missing a discussion of the
first case. Here it may even be that existing mechanisms
already solve the problem, because presumably RFC 3484
would not select source addresses from a link that's down.
But it would still be important to note this.

>   The missing part is a mechanism to convey the information from the
>   server to the host.  A possible option is to define a new DHCP option
>   to transmit policy table information.
>  
>
This does not appear to be able to deal with dynamic
outages, or does it? At the very least the lease times
would have to be set low.

>   It is also possible to enable the multihomed host to query the server
>   to obtain the source address prefix information as proposed in [6] .
>   In this case, each time the multihomed node initiates a communication
>   with a new destiantion, it would query the server for the proper
>   prefix to include in the source address.  The server, would reply
>   based on the routing information it has gathered through BGP.
>  
>
This might be a better alternative, perhaps modified by
only doing the query if you can't establish a connection.

>   The first option is to simply let the upper layers to handle
>   retrials.  In this case, the IP layer only has to make sure that a
>   different source address is used in each retrial as long as there is
>   not a preferred source address in the source address cache.  So, in
>   this approach, when the IP layer receives a packet, it searches the
>   Source Address Cache for a preferred source address associated to the
>   selected destination.  If no entry exists for that destination
>   address, one of the available source addresses is selected randomly.
>   If reply packets arrive, an entry will be created in the Source
>   Address Cache for that destination address.  If no reply packets
>   arrive, no entry will be created, so when the upper layer protocol
>   resends the packet, a new source address will be used.
>  
>
I may be confused here, but I suppose you are not talking
about IP packets, you are talking about connection initiation.
You can't change source address on the fly from an existing
TCP sessions.

--Jari

Delivery-date: Tue, 04 Oct 2005 21:42:49 +0000
Cc: John Payne <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, David Meyer <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Tony Li <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
Date: Tue, 4 Oct 2005 14:41:59 -0700
To: "Jason Schiller ([email-masked])" <[email-masked]>

>>> NANOG = network operators in the sense of ISPs and the like. The
>>> solution that the shim6 is working on does NOT apply to this
>>> demographic.
>>>

The ISP community is the primary direct beneficiary of shim6 and will  
have to work with their customers to help implement it.  If the  
operational community is interested in the long term scalability of  
the routing subsystem, then we need to implement the changes to the  
routing architecture necessary to not advertise per-organization  
prefixes globally and shim6 is the best way that we have of doing that.

Shim6 needs ISP support, plain and simple.

Tony

Delivery-date: Tue, 04 Oct 2005 20:44:06 +0000
Date: Wed, 05 Oct 2005 06:42:12 +1000
To: "Jason Schiller ([email-masked])" <[email-masked]>, John Payne <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
Cc: Iljitsch van Beijnum <[email-masked]>, David Meyer <[email-masked]>, [email-masked], [email-masked], [email-masked]

>Doesn't this apply to any orgization that doesn't have its own /32?

In the fullness of time this is the expectation, yes. However its pretty clear
that the approach entails some changes to the protocol stack, and its not going
to be a completely straightforward task. So its a pretty likely outcome 
that the
'conventional' practice of advertising more specifics into the routing system
will not disappear overnight.

>Doesn't this apply to any orgization that has customers that require
>multihoming but lack their own /32 as John points out?

as above.

>Doesn't this apply to any orgization that has it's own IPv6 aggregate,
>and wants to advertise something more specific than its aggregate?
>
>If that is the case, then it won't just apply to ISPs or multi-homed end
>sites who can't get a /32, it also applies to ISPs and end sites who have
>a /32, but need to split route announcement to share load across multiple
>transit providers.

I can appreciate the logic here- but in the same way that it strikes
me that using routing to perform fine-grained traffic engineering is akin
to using a mallet and an axe for a task that normally requires a micro-surgery,
this also strikes me as a very round-about way to get to a useful approach
to realize localized traffic engineering.

regards,

     Geoff

Delivery-date: Tue, 04 Oct 2005 20:05:33 +0000
Date: Tue, 04 Oct 2005 15:54:10 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
To: John Payne <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, David Meyer <[email-masked]>, [email-masked], [email-masked], [email-masked]

On Tue, 4 Oct 2005, John Payne wrote:

> Date: Tue, 04 Oct 2005 14:10:27 -0400
> From: John Payne <[email-masked]>
> To: Iljitsch van Beijnum <[email-masked]>
> Cc: David Meyer <[email-masked]>, [email-masked], [email-masked], [email-masked]
> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
> 
> 
> On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote:
> 
> > NANOG = network operators in the sense of ISPs and the like. The 
> > solution that the shim6 is working on does NOT apply to this 
> > demographic.
> 
> Whoa there.  The NANOG community (as well as other ISP communities) is 
> hugely affected by shim6.
> 
> They are the ones who will be fielding customer calls about multihoming 
> - "why can't I just setup BGP like I always have done?".  Not everyone 
> at NANOG is going to be big enough to get a /32, but most of the ISPs 
> there are at least multihomed today.

> > I urge the discussion leaders to make it painfully clear to which
> > types of users the shim6 solution space applies and to which type of
> > users it doesn't.

Doesn't this apply to any orgization that doesn't have its own /32?

Doesn't this apply to any orgization that has customers that require
multihoming but lack their own /32 as John points out? 

Doesn't this apply to any orgization that has it's own IPv6 aggregate,
and wants to advertise something more specific than its aggregate?

If that is the case, then it won't just apply to ISPs or multi-homed end
sites who can't get a /32, it also applies to ISPs and end sites who have
a /32, but need to split route announcement to share load across multiple
transit providers.

___Jason

Delivery-date: Tue, 04 Oct 2005 19:16:05 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 21:15:00 +0200
To: John Payne <[email-masked]>

On 4-okt-2005, at 20:43, John Payne wrote:

>> Do people really buy lines just to use them as backups? I never  
>> understood this.

> Absolutely.  I am concerned by your need to state that you don't  
> understand why.
> If you've never been in that position, you don't need to understand  
> it, other than to accept that it exists.

But it doesn't make any sense. If you're paying for the link, why not  
use it? Or do the service providers make the deal such that it's  
cheaper to have the link be idle?

It's also not very good engineering: expecting something that is  
never used to work suddenly is asking for trouble.

>>> our you can load share by splitting your announcements
>>> across you links.

>> Yuck, you should never announce more specifics for this.

> Never is a strong word.  If I have multiple uplinks to the same  
> provider, it
> affects NOBODY but my provider and me if I deaggregate and tag no- 
> export to load balance across those multiple links.  It's  
> especially useful if those links are geographically diverse.

Sure, but if it only happens between you and your ISP then I don't  
care anyway, so why bring it up? The multihoming problem that shim6  
wants to solve is multihoming to two or more ISPs.

Delivery-date: Tue, 04 Oct 2005 11:30:21 +0000
Date: Tue, 4 Oct 2005 12:30:08 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Tue, 4 Oct 2005, marcelo bagnulo braun wrote:

> HBA are constructed using regular PA prefixes assigned by the ISPs 
> (LIRs) that are serving the multihomed site. Just regular PA 
> prefixes. The HBA essentially defines the iid

Ah, yes. So you end up with a set of HBAs all of which have provider 
assigned prefix as their own prefix, that point had escaped me. 
Thanks. (And advertise a set of HBAs in DNS. And all reachable even 
without shimming).

I was confused and thought there would be a special shim prefix to 
which the HBA IID would be joined.

> i think that Jari and Erik have clearly explained this point

Yes. ;)

> i agree that this is a great benefit of current IPv4 PI address based 
> solution, but this is clearly not the goal of the shim6 wg

Right. Shame, but hey.

Thanks!

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
No hardware designer should be allowed to produce any piece of hardware
until three software guys have signed off for it.
 		-- Andy Tanenbaum

Delivery-date: Tue, 04 Oct 2005 11:23:29 +0000
Date: Tue, 4 Oct 2005 12:23:05 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Tue, 4 Oct 2005, marcelo bagnulo braun wrote:

> I think that it is important to distinguish the two cases that Erik presented 
> in a mail earlier:

> are we considering the case of a proxy for legacy hosts or are we supposing 
> that hosts within the multihomed site support the shim functionality and that 
> the proxy is simply performing source address /prefix selection for that 
> hosts?

I've been considering the case where hosts where not enabling their 
shims so far.

> These are two very different problems imho the second is quite easy 
> imho but the second is quite hard and this is where the issues of 
> dhcp, coordination, single point of failure in the proxy becomes an 
> issue.

Yes, the second is trickier. I hadn't considered the second case, 
thanks for making it clear Erik was. ;)

To deal with the second case depends on how a shim-aware host decides 
to enable shim, I would guess.

The simplest way possibly would be to have a way to suppress end-host 
shim at a site which had shim proxies available.

> regards, marcelo

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
  "Look at that five o'clock rust. You've been up all night not drinking,
haven't you?" -Leela

Delivery-date: Tue, 04 Oct 2005 11:00:01 +0000
Cc: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 13:00:48 +0200
To: Paul Jakma <[email-masked]>

Paul,

El 04/10/2005, a las 12:31, Paul Jakma escribi=F3:

> On Mon, 3 Oct 2005, Erik Nordmark wrote:
>
>> Sure. But that assumes that the hosts know their addresses.
>
> They do. It would be the address they are using.
>
>> As I understood it, a host would configure its IPv6 address as today=20=

>> (stateless, DHCPv6, etc). And the shim proxy would form a HBA=20
>> parameter set (based on the prefixes assigned to the site) for each=20=

>> host and run a 1:1 NAT. In that case the host doesn't know which IPv6=20=

>> address the proxy has picked for it.
>
> The proxy wouldn't pick addresses, it would only map prefixes. So the=20=

> end-host inside the shimmed area could use a CGA address (thanks btw=20=

> for helping me to prod my brain into grokking them offline ;) ). Ie:
>

i getting somehow confused here...

I think that it is important to distinguish the two cases that Erik=20
presented in a mail earlier:
are we considering the case of a proxy for legacy hosts or are we=20
supposing that hosts within the multihomed site support the shim=20
functionality and that the proxy is simply performing source address=20
/prefix selection for that hosts?

These are two very different problems imho
the second is quite easy imho but the second is quite hard and this is=20=

where the issues of dhcp, coordination, single point of failure in the=20=

proxy becomes an issue.

regards, marcelo

> host uses: <prefix>:<CGA interface identifier>
>
> (a shim6 ULID essentially, even if the host isn't quite aware of =
this).
>
> Proxy: maps <prefix> to <LocatorN> according to established shim6
>        protocols.
>
>> Or where you thinking that the host could only use DHCPv6 and the=20
>> shim proxy and the DHCP server would coordinate things so that the=20
>> host is informed of its shimmed addresses?
>
> The host might /only/ have a shimmed address.
>
> It might also have other addresses, I don't know. Sadly there isn't a=20=

> good way that I know of to indicate metrics for prefix-advertisements.
>
>> You mean you assume it is ok to publish unreachable addresses in the=20=

>> DNS?
>
> Why wouldn't it be exactly? Publishing something in DNS is no=20
> guarantee of reachability. It would be /intended/ to be reachable, via=20=

> shim6.
>
> The taboo was on non-globally-unique addresses in DNS, i thought?
>
>> Even if folks agree on that, the fact that the internal hosts would=20=

>> see both the local/internal address, and the shimmed addresses, would=20=

>> mean that they might seeming randomly end up using the shimmed=20
>> addresses, and such internal communication ends up going via the=20
>> proxy.
>
> Not sure why that'd be so. It's an interior routing issue.
>
> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> Peter's hungry, time to eat lunch.
>

Delivery-date: Tue, 04 Oct 2005 10:52:02 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 12:52:47 +0200
To: Paul Jakma <[email-masked]>

El 03/10/2005, a las 15:58, Paul Jakma escribi=F3:

> On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:
>
>> i am not sure what you mean here, nut just for stating things=20
>> precisely, HBA do have globally assigned prefixes
>
> Uh, ah. I didn't realise that. Who assigns them?

HBA are constructed using regular PA prefixes assigned by the ISPs=20
(LIRs) that are serving the multihomed site. Just regular PA prefixes.=20=

The HBA essentially defines the iid

>  And surely the point of HBA is that they can be locally assigned?

Well, the iid is locally generated (as any IPv6 address) but the prefix=20=

is asigned by the LIR as any PA prefix

>  (Or do you mean HBA's stand a very good chance of being globally=20
> /unique/?).
>

no, HBA are administratively unique (as opposed to statistically unique)

>>> I had, in my mind, been considering that there would be a mechanism=20=

>>> to allow the prefix set -> ULID mapping to change
>>
>> there is, the CGA part of the HBA/CGA hybrid addresses.
>
>> That is why there are three flavors of addresses:
>> - HBA that support a static set of addresses that cannot be changed=20=

>> during the lifetime of an established communication (with the cost of=20=

>> a hash per address)
>> - CGA/HBA that support a stable prefix set and additional addresses=20=

>> that can be added during the lifetime of the communications (the cost=20=

>> of the stable addresses is a hash operation while the cost of a new=20=

>> address (out of the initial set) is a public key operation)
>> - CGA addresses, any addresses can be used with the cost of a public=20=

>> key operation
>
> I'd have to ask: Why use CGA?

i think that Jari and Erik have clearly explained this point

>
> AFAICT, CGA was created specifically because relying on IPSec for=20
> address assignment has bootstrap issues. Hence CGA and SeND.
>
> For modes relying on anonymously introduced public-key cryptography,=20=

> we won't have bootstrap issues here, so why not use standard IPSec? Is=20=

> it just to avoid the size of an AH header on each packet?
>
> How will you communicate the CGA parameters? Is shim to reinvent=20
> portions of IKE in order to communicate public keys? Why not just use=20=

> IKE? IPSec is well-understood, widely implemented and deployed. Why=20
> give ourselves the task of reinventing aspects of it?
>
> I can see some of the attractions of HBA, but using CGA beyond the=20
> local-link is stretching it..
>
> (That's not to say a host that was configured with a key for CGA=20
> couldn't use the same public key for IPSec..)
>
>> However, you should note that the public key used is included in the=20=

>> hash that results in the interface identifier of the addresses
>
> Ok.
>
>>> fairly big cost in functionality. (Eg, what exactly would shim6=20
>>> using invariant HBAs offer over application layer remapping support?
>>
>> i am not sure i understand what you mean here... could you expand?
>
> For me, the prime benefit of multihoming is not so much having=20
> multiple links but having number portability and the ability to easily=20=

> transfer between providers[1]. Eg, shim'ing but having only one=20
> provider would be something I'd be interested in if it gave me=20
> portability. It's been a big reason for multihoming for two=20
> organisations I've worked with.
>

i agree that this is a great benefit of current IPv4 PI address based=20
solution, but this is clearly not the goal of the shim6 wg

> Without portability, you're left only with solving failure events=20
> amongst multihomed links.

I would rephrase it a bit more general, like: the goal of the shim is=20
to preserve established communications through outages
but yes, portability in the sense of PI addresses are not part of the=20
scope of the shim work

>  And I don't think you need a shim layer for this, personally.

here we disagree (but we have already discuss this point)

regards, marcelo

>
> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> travel, n.:
> 	Something that makes you feel like you're getting somewhere.
>

Delivery-date: Tue, 04 Oct 2005 10:36:37 +0000
Date: Tue, 4 Oct 2005 11:35:53 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Tue, 4 Oct 2005, Iljitsch van Beijnum wrote:

> 4.4 DNS Issues
>
>  At the present time AAAA and PTR records for locally assigned local
>  IPv6 addresses are not recommended to be installed in the global DNS.
>  The operational issues relating to this are beyond the scope of this
>  document.
>
> Since obviously address that don't appear in the DNS aren't usable in 
> practice, this passage effectively requires two-faced DNS.

Maybe we're not using same definition of two-faced DNS (different 
answers for same query based on query-source), but there are other 
ways to deal with above than two-faced DNS, eg put RR's which refer 
to local-scope addresses in zones which can be queried only from that 
same scope.

Works a treat.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"I'm not a god, I was misquoted."
-- Lister, Red Dwarf

Delivery-date: Tue, 04 Oct 2005 10:32:45 +0000
Date: Tue, 4 Oct 2005 11:31:36 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Erik Nordmark wrote:

> Sure. But that assumes that the hosts know their addresses.

They do. It would be the address they are using.

> As I understood it, a host would configure its IPv6 address as 
> today (stateless, DHCPv6, etc). And the shim proxy would form a HBA 
> parameter set (based on the prefixes assigned to the site) for each 
> host and run a 1:1 NAT. In that case the host doesn't know which 
> IPv6 address the proxy has picked for it.

The proxy wouldn't pick addresses, it would only map prefixes. So the 
end-host inside the shimmed area could use a CGA address (thanks btw 
for helping me to prod my brain into grokking them offline ;) ). Ie:

host uses: <prefix>:<CGA interface identifier>

(a shim6 ULID essentially, even if the host isn't quite aware of 
this).

Proxy: maps <prefix> to <LocatorN> according to established shim6
        protocols.

> Or where you thinking that the host could only use DHCPv6 and the 
> shim proxy and the DHCP server would coordinate things so that the 
> host is informed of its shimmed addresses?

The host might /only/ have a shimmed address.

It might also have other addresses, I don't know. Sadly there isn't a 
good way that I know of to indicate metrics for 
prefix-advertisements.

> You mean you assume it is ok to publish unreachable addresses in 
> the DNS?

Why wouldn't it be exactly? Publishing something in DNS is no 
guarantee of reachability. It would be /intended/ to be reachable, 
via shim6.

The taboo was on non-globally-unique addresses in DNS, i thought?

> Even if folks agree on that, the fact that the internal hosts would 
> see both the local/internal address, and the shimmed addresses, 
> would mean that they might seeming randomly end up using the 
> shimmed addresses, and such internal communication ends up going 
> via the proxy.

Not sure why that'd be so. It's an interior routing issue.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Peter's hungry, time to eat lunch.

Delivery-date: Tue, 04 Oct 2005 07:56:55 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Fwd: I-D ACTION:draft-bagnulo-shim6-addr-selection-00.txt 
Date: Tue, 4 Oct 2005 09:57:16 +0200

Hi,

i have submitted the attached draft for consideration to the wg.

The goal o this draft is to consider different mechanisms to initiate  
communications between hosts within the multihomed site and external  
legacy hosts after an outage. BEcause of that, the considered  
mechanisms only affect the hosts within the multihomed site (as oposed  
to the shim mechanisms, which involve both multihomed hosts and  
external hosts)

The draft is an attempt to tackle the item described in the charter as:

In addition to the network layer shim solution, the shim6 WG is
specifically chartered to work on:

...

o Solutions to establish new communications after an outage has
occurred that do not require shim support from the
non-multihomed end of the communication. The Working Group will
explore whether such solutions are also useful when both ends
support the shim.

In its current form, the draft presents several mechanisms that have  
been considered for dealing with this.
At this stage, the goal is mostly to foster discussion on this topic  
and see if we can come up with better approaches to deal with this (or  
convince ourselves that this mechanisms available are not so bad :-)

So, any feedback is welcome.

Thanks, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 3 de octubre de 2005 21:50:02 GMT+02:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-bagnulo-shim6-addr-selection-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: Address selection in multihomed environments
> 	Author(s)	: M. Bagnulo
> 	Filename	: draft-bagnulo-shim6-addr-selection-00.txt
> 	Pages		: 17
> 	Date		: 2005-10-3
> 	
>    This note describes mechanisms for address selection in hosts within
>    a multihomed site.  The goal of these mechanisms is to allow hosts
>    within the multihomed site to establish new communications after an
>    outage.  The presented mechanisms are not by themselves a complete
>    multihoming solution but rather a component of such solution.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-addr- 
> selection-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-addr-selection-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-addr-selection-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: Mon, 03 Oct 2005 22:46:39 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 00:46:21 +0200
To: Erik Nordmark <[email-masked]>

On 3-okt-2005, at 23:38, Erik Nordmark wrote:

> As I understood it, a host would configure its IPv6 address as  
> today (stateless, DHCPv6, etc). And the shim proxy would form a HBA  
> parameter set (based on the prefixes assigned to the site) for each  
> host and run a 1:1 NAT. In that case the host doesn't know which  
> IPv6 address the proxy has picked for it.

I would rather avoid that... Although the harmful effects of the NAT  
could be limited to legacy communication if the shim is established  
immediately and the remote end is informed that we use an identifier  
that's different from the locators.

> Or where you thinking that the host could only use DHCPv6 and the  
> shim proxy and the DHCP server would coordinate things so that the  
> host is informed of its shimmed addresses?

Although configuring non-shim hosts with a specific address (with the  
correct HBA interface identifier) is somewhat difficult, this is an  
operational problem that can be solved in a variety of ways using  
standard system administration approaches. While having a NAT in the  
middle requires changes from applications to work through the NAT,  
which is much, much harder to accomplish.

>> You wouldn't need split DNS for the shim6 site-intermediary case  
>> AFAICT, because the locator addresses would never be reachable -  
>> only the mapped address would ever be a valid address to try reach.

> You mean you assume it is ok to publish unreachable addresses in  
> the DNS?

If address policy mechanisms work well, this shouldn't be an issue:  
try unique site locals first if they match our /48, last if they  
don't. But currently, address policies aren't implemented widely and  
mechanisms to automatically adjust them not at all, AFAIK.

Delivery-date: Mon, 03 Oct 2005 22:39:08 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 00:38:58 +0200
To: Paul Jakma <[email-masked]>

On 3-okt-2005, at 23:11, Paul Jakma wrote:

> Split DNS is fairly evil btw.

It is. But just remember to set the evil bit and you're ok...

 From draft-ietf-ipv6-unique-local-addr-09.txt:

4.4 DNS Issues

    At the present time AAAA and PTR records for locally assigned local
    IPv6 addresses are not recommended to be installed in the global  
DNS.
    The operational issues relating to this are beyond the scope of this
    document.

Since obviously address that don't appear in the DNS aren't usable in  
practice, this passage effectively requires two-faced DNS.

Delivery-date: Mon, 03 Oct 2005 22:32:34 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Tue, 4 Oct 2005 00:31:56 +0200
To: Paul Jakma <[email-masked]>

[I'm sure all the people on the CC list are very happy to receive two  
copies of these messages for no apparent reason]

On 3-okt-2005, at 22:47, Paul Jakma wrote:

> (You might even advertise it to some of your 'close' AS-friends via  
> BGP, using either something like the possible 'AS_HOPCOUNT'  
> attribute to limit its scope, or NO-EXPORT).

Yeah that doesn't work too well. Some people strip off all  
communities on incoming routes.

Delivery-date: Mon, 03 Oct 2005 21:38:28 +0000
Date: Mon, 03 Oct 2005 14:38:49 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

>  From experience, you can do static NAT at your border for a set of 
> prefixes while routing them internally normally. The NAT is quite 
> invisible within your AS, as it is outside your AS - only your borders 
> know it.

Sure. But that assumes that the hosts know their addresses.

AFAICT in this case a host in the site wouldn't know what IPv6 address 
the shim proxy has assigned to it, and placed in the (external) DNS.

As I understood it, a host would configure its IPv6 address as today 
(stateless, DHCPv6, etc). And the shim proxy would form a HBA parameter 
set (based on the prefixes assigned to the site) for each host and run a 
1:1 NAT. In that case the host doesn't know which IPv6 address the proxy 
has picked for it.

Or where you thinking that the host could only use DHCPv6 and the shim 
proxy and the DHCP server would coordinate things so that the host is 
informed of its shimmed addresses?

> You wouldn't need split DNS for the shim6 site-intermediary case AFAICT, 
> because the locator addresses would never be reachable - only the mapped 
> address would ever be a valid address to try reach.

You mean you assume it is ok to publish unreachable addresses in the DNS?
Even if folks agree on that, the fact that the internal hosts would see 
both the local/internal address, and the shimmed addresses, would mean 
that they might seeming randomly end up using the shimmed addresses, and 
such internal communication ends up going via the proxy.

    Erik

Delivery-date: Mon, 03 Oct 2005 21:11:54 +0000
Date: Mon, 3 Oct 2005 22:11:33 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Erik Nordmark wrote:

> But the hosts don't even know they are assigned this prefix; it's 
> the shim that does it for them.
>
> Which is why I think this approach (like other NATish approaches) most likely 
> ends up requiring a two-faced DNS.

>From experience, you can do static NAT at your border for a set of 
prefixes while routing them internally normally. The NAT is quite 
invisible within your AS, as it is outside your AS - only your 
borders know it.

You wouldn't need split DNS for the shim6 site-intermediary case 
AFAICT, because the locator addresses would never be reachable - only 
the mapped address would ever be a valid address to try reach.

Split DNS is fairly evil btw.

> That might be ok; we just have to understand the implications.

Aye.

>   Erik

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
love,  n.:
 	Love ties in a knot in the end of the rope.

Delivery-date: Mon, 03 Oct 2005 20:56:28 +0000
Date: Mon, 03 Oct 2005 13:56:33 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

>> Extend this to a site with, say 20,000 hosts, starting to use the shim 
>> for multihoming benefits. They might be a bit surprised when all their 
>> internal traffic go through (a single) shim proxy which melts under 
>> the load.
> 
> 
> That would be highly annoying yes. ;) I suspect though it would be far 
> more fruitful to route this prefix normally within ones own domain. ;)
> 

But the hosts don't even know they are assigned this prefix; it's the 
shim that does it for them.

Which is why I think this approach (like other NATish approaches) most 
likely ends up requiring a two-faced DNS.

That might be ok; we just have to understand the implications.
(It's not like I have a better way to do a shim proxy for legacy IPv6 
hosts.)

    Erik

Delivery-date: Mon, 03 Oct 2005 20:47:46 +0000
Date: Mon, 3 Oct 2005 21:47:28 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Erik Nordmark wrote:

> In that case, if an inside host tries to contact the host (in the 
> same site) which uses the proxy for shimming, all the packets would 
> have to go via the proxy.

Oof.

> Extend this to a site with, say 20,000 hosts, starting to use the 
> shim for multihoming benefits. They might be a bit surprised when 
> all their internal traffic go through (a single) shim proxy which 
> melts under the load.

That would be highly annoying yes. ;) I suspect though it would be 
far more fruitful to route this prefix normally within ones own 
domain. ;)

(You might even advertise it to some of your 'close' AS-friends via 
BGP, using either something like the possible 'AS_HOPCOUNT' attribute 
to limit its scope, or NO-EXPORT).

>   Erik

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Lend money to a bad debtor and he will hate you.

Delivery-date: Mon, 03 Oct 2005 20:47:00 +0000
Date: Mon, 03 Oct 2005 13:47:24 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:
> On Mon, 3 Oct 2005, Erik Nordmark wrote:
> 
>> There is a qualitative difference between the various leap-of-faith 
>> security schemes (ssh being one example, I think BTNS is talking of 
>> adding the same thing to IPsec), and HBA/CGA as it comes to securing 
>> the locator changes in shim6.
> 
> 
> Surely we ought to distinguish CGA from HBA here? Only HBA provides a 
> unique mapping. CGA is just 'anonymous' public key crypto, as IPSec is. 
> IPSec at least does /allow/ for key exchange schemes other than 
> anonymous keys, like X.509 cert chains, GSS-API, etc.

No, CGA is qualitatively different to IPsec leap-of-faith as in HBA.
Thus for the perspective of understanding how IPsec leap-of-faith is 
different than what we have on the table with HBA/CGA, the CGA vs. HBA 
difference isn't critical.
(That doesn't mean that CGA and HBA are identical, but they are the same 
in that neither of them rely on leap-of-faith.)

>> Thus the only want Bob can pretend to be Alice (and have the same IP 
>> address) is to use the identical HBA parameter data structure. (This 
>> isn't hard, since the parameters are sent in the clear.)
> 
> 
> Note that if Bob is not MITM, he can still get Alice's HBA, though it 
> requires Bob to first communicate with Alice. Eg with some innocent 
> unrelated pretence.

Yes.

>> Unlike leap-of-faith schemes, which as part of their nature end up 
>> assuming that the first host to connect is who they claim to be, the 
>> intrinsic result of having a hash of something in the interface-id in 
>> the address, is that we don't need to make any such leap of faith. 
>> Which means that we can have a lot more flexibility when it comes to 
>> handling attackers like Bob above who is on the path for some amount 
>> of the time, but perhaps isn't permanently on the path.
> 
> 
> Yes, it's a very nice property of HBA, I must admit. Though, it does 
> completely rule out number portability, seemingly (in terms of ULIDs).

But the alternative is leap-of-faith, which, depending on the details, 
might allow my laptop to fool your laptop into it thinking my laptop is 
  www.google.com with very little effort.

I think being able to recover from a MiTM as soon as the MiTM moves off 
the path is an important property.

(FWIW some of this is discussed in 
draft-ietf-multi6-multihoming-threats-03.txt, which is in the RFC 
editors queue.)

   Erik

Delivery-date: Mon, 03 Oct 2005 20:40:42 +0000
Date: Mon, 03 Oct 2005 13:41:09 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:
> On Mon, 3 Oct 2005, Erik Nordmark wrote:
> 
>> In this case, what would the AAAA records in the DNS contain for the 
>> hosts?
> 
> 
> The shim-mapped address. It'd be the only address the hosts would 
> reachable on.

In that case, if an inside host tries to contact the host (in the same 
site) which uses the proxy for shimming, all the packets would have to 
go via the proxy.

Extend this to a site with, say 20,000 hosts, starting to use the shim 
for multihoming benefits. They might be a bit surprised when all their 
internal traffic go through (a single) shim proxy which melts under the 
load.

    Erik

>> Seems like the hosts in the same site would want to see the regular 
>> IPv6 address the host picked, while other hosts need to see the shim 
>> assigned address.
> 
> 
> Nah, everyone would use shim. 'outside' hosts would need to speak shim.
> 
>> Doesn't this mean that this approach requires a two-faced DNS for the 
>> site?
> 
> 
> Oof no :), anything but that.
> 
> regards,

Delivery-date: Mon, 03 Oct 2005 20:37:43 +0000
Subject: I-D ACTION:draft-ietf-shim6-proto-00.txt
From: Jeroen Massar <[email-masked]>
To: shim6 <[email-masked]>
Organization: Unfix
Date: Mon, 03 Oct 2005 22:37:15 +0200

--=-PPS+BGmqzGP+MKiHZLvM
Content-Type: multipart/mixed; boundary="=-QnVF2t/k7p6jHAKQvyWF"

--=-QnVF2t/k7p6jHAKQvyWF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Just appeared :)

-------- Forwarded Message --------
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-proto-00.txt
Date: Mon, 03 Oct 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Site Multihoming by IPv6 Intermediation Wo=
rking Group of the IETF.

	Title		: Level 3 multihoming shim protocol
	Author(s)	: E. Nordmark
	Filename	: draft-ietf-shim6-proto-00.txt
	Pages		: 61
	Date		: 2005-10-3
=09
   The SHIM6 working group is exploring a layer 3 shim approach for
   providing locator agility below the transport protocols, so that
   multihoming can be provided for IPv6 with failover and load spreading
   properties, without assuming that a multihomed site will have a
   provider independent IPv6 address which is announced in the global
   IPv6 routing table.  The hosts in a site which has multiple provider
   allocated IPv6 address prefixes, will use the shim6 protocol
   specified in this document to setup state with peer hosts, so that
   the state can later be used to failover to a different locator pair,
   should the original one stop working.

   This document picks a particular approach to such a protocol and
   tries to flush out a bunch of details, with the hope that the WG can
   better understand the details in this proposal as well as discovering
   and understanding alternative designs that might be better.  Thus
   this proposal is my no means cast in stone as the direction; quite to
   the contrary it is a depth first exploration of the design space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of the =
message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the usernam=
e
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-shim6-proto-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-ietf-shim6-proto-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--=-QnVF2t/k7p6jHAKQvyWF
Content-Type: Message/External-body; access-type="mail-server"; server="[email-masked]"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA1LTEwLTMxMzE4MDAuSS1E
QGlldGYub3JnPgoKRU5DT0RJTkcgbWltZQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1zaGltNi1wcm90by0wMC50eHQK

--=-QnVF2t/k7p6jHAKQvyWF
Content-Type: Message/External-body; name="draft-ietf-shim6-proto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA1LTEwLTMxMzE4MDAuSS1E
QGlldGYub3JnPgoK

--=-QnVF2t/k7p6jHAKQvyWF--

--=-PPS+BGmqzGP+MKiHZLvM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-PPS+BGmqzGP+MKiHZLvM--

Delivery-date: Mon, 03 Oct 2005 20:03:33 +0000
Date: Mon, 3 Oct 2005 21:02:49 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Erik Nordmark wrote:

> There is a qualitative difference between the various leap-of-faith 
> security schemes (ssh being one example, I think BTNS is talking of 
> adding the same thing to IPsec), and HBA/CGA as it comes to 
> securing the locator changes in shim6.

Surely we ought to distinguish CGA from HBA here? Only HBA provides a 
unique mapping. CGA is just 'anonymous' public key crypto, as IPSec 
is. IPSec at least does /allow/ for key exchange schemes other than 
anonymous keys, like X.509 cert chains, GSS-API, etc.

> Thus in effect, the leap-of-faith provides a first-come-first-serve 
> approach to anybody wanting to claim an IP address as theirs.

Yep.

> Compare this with using HBA.
> With HBA Alice and Cesar will create the IPv6 address(es) as a hash of some 
> things.
>
> Thus the only want Bob can pretend to be Alice (and have the same 
> IP address) is to use the identical HBA parameter data structure. 
> (This isn't hard, since the parameters are sent in the clear.)

Note that if Bob is not MITM, he can still get Alice's HBA, though it 
requires Bob to first communicate with Alice. Eg with some innocent 
unrelated pretence.

> Unlike leap-of-faith schemes, which as part of their nature end up 
> assuming that the first host to connect is who they claim to be, 
> the intrinsic result of having a hash of something in the 
> interface-id in the address, is that we don't need to make any such 
> leap of faith. Which means that we can have a lot more flexibility 
> when it comes to handling attackers like Bob above who is on the 
> path for some amount of the time, but perhaps isn't permanently on 
> the path.

Yes, it's a very nice property of HBA, I must admit. Though, it does 
completely rule out number portability, seemingly (in terms of 
ULIDs).

>   Erik

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
When I got up this morning I took two Ex-Lax in addition to my Prozac.
I can't get off the john, but I feel good about it.

Delivery-date: Mon, 03 Oct 2005 19:52:52 +0000
Date: Mon, 3 Oct 2005 20:52:08 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Erik Nordmark wrote:

> In this case, what would the AAAA records in the DNS contain for 
> the hosts?

The shim-mapped address. It'd be the only address the hosts would 
reachable on.

> Seems like the hosts in the same site would want to see the regular 
> IPv6 address the host picked, while other hosts need to see the 
> shim assigned address.

Nah, everyone would use shim. 'outside' hosts would need to speak 
shim.

> Doesn't this mean that this approach requires a two-faced DNS for 
> the site?

Oof no :), anything but that.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Ignorance must certainly be bliss or there wouldn't be so many people
so resolutely pursuing it.

Delivery-date: Mon, 03 Oct 2005 17:59:10 +0000
Date: Mon, 03 Oct 2005 10:59:09 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked], shim6-wg <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

[Seems like the topic hasn't anything to do with the subject line any 
more ;-) ]

Paul Jakma wrote:

> That's the same thing you could achieve with anonymous IPSec. (Though, 
> IPSec associates state with a 'security association' rather than 
> address, which could be more fine-grained than CGA). It's an anonymous 
> key either way, unless there is some other way to verify the 
> authenticity of a key and what it may be used for / who it is issued for 
> (who in terms of IP addresses).

There is a qualitative difference between the various leap-of-faith 
security schemes (ssh being one example, I think BTNS is talking of 
adding the same thing to IPsec), and HBA/CGA as it comes to securing the 
locator changes in shim6.

Let me take an example:
We have Alice and Bob on the IETF wireless network, and Cesar being some 
remote site (e.g., www.google.com).

If Bob can predict that Alice will communicate with Cesar, the if a 
leap-of-faith approach is used, Bob can contact Cesar and pretend to be 
Alice, and create state on Cesar (ssh key fingerprints, IPsec/IKE SAs).
This is trivial when Alice and Bob are on the same IP link. This state 
will be associated with Alice's IP address.

The effect of this is that Alice will fail to communicate with Cesar, 
since the created state is in the way; Cesar will conclude that Alice is
an impostor who is trying to be Bob and does not have the correct key.

Thus in effect, the leap-of-faith provides a first-come-first-serve 
approach to anybody wanting to claim an IP address as theirs.

And the attack can also be done in the reverse direction; Bob contacting 
Alice pretending to Cesar and creating state on Alice that will prevent 
Alice from talking to the real Cesar.

Note that these attacks assume that Bob can be a MiTM for a at least 
short time so that it can create the state.
But the effect of a short presence can be long lived; it depends on how 
quickly (if ever) the particular security mechanism on Cesar will 
discard the state for Alice. Typical IKE/IPsec timeouts might be 
measured in hours.

Compare this with using HBA.
With HBA Alice and Cesar will create the IPv6 address(es) as a hash of 
some things.

Thus the only want Bob can pretend to be Alice (and have the same IP 
address) is to use the identical HBA parameter data structure. (This 
isn't hard, since the parameters are sent in the clear.)

When it does this and communicates with Cesar, there will be shim6 state 
setup on Cesar for Alice's IP address and its HBA parameter structure. 
As part of this there will be some cookie (shim6 context tag) exchanged 
between Bob (pretending to be Alice) and Cesar, but there are no session 
keys or other long-lived material setup as part of the context, except 
from Alice's HBA parameter data structure.

What happens when Alice tries to setup a shim6 context with Cesar?
Well, the details have to be specified, but I suspect it's just a matter 
of Cesar verifying that the locator for Alice is the same as before, but 
that Alice doesn't have the context tag, and which point Cesar can tell 
Alice what context tag to use.

Unlike leap-of-faith schemes, which as part of their nature end up 
assuming that the first host to connect is who they claim to be, the 
intrinsic result of having a hash of something in the interface-id in 
the address, is that we don't need to make any such leap of faith.
Which means that we can have a lot more flexibility when it comes to 
handling attackers like Bob above who is on the path for some amount of 
the time, but perhaps isn't permanently on the path.

    Erik

Delivery-date: Mon, 03 Oct 2005 17:20:38 +0000
Date: Mon, 03 Oct 2005 10:19:43 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:
> site shim6 ->
>      hosts are assigned ULIDs from a stable, invariant address range.
>      hosts just use regular IPv6 stacks and regular ways to
>        assign themselves IPv6 addresses
>      intermediary does shim6, 1:1 mapping.

In this case, what would the AAAA records in the DNS contain for the hosts?
Seems like the hosts in the same site would want to see the regular IPv6 
address the host picked, while other hosts need to see the shim assigned 
address.
Doesn't this mean that this approach requires a two-faced DNS for the site?

   Erik

Delivery-date: Mon, 03 Oct 2005 16:39:21 +0000
Date: Mon, 03 Oct 2005 19:39:08 +0300
From: Jari Arkko <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

> Interesting. <comments sent off list>

Thanks!

> Apologies, I'm not questioning CGA and it's use with SeND at all.
>
> I'm questioning wider off-link, non-ND use of CGA, eg with Shim.

Sure. And I did not want to start an argument on whether we
should or should not use CGA. Just providing information on
a previous case and why an IPsec solution did not work well
for that.

But I wanted disagree on CGA being very different in terms
of its on or off link usage and the need for IKE with either
HBA or CGA.

--Jari

Delivery-date: Mon, 03 Oct 2005 16:21:00 +0000
Date: Mon, 3 Oct 2005 17:20:36 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Jari Arkko wrote:

> has most often failed. See http://www.arkko.com/publications/SWP03.pdf
> for a discussion of some of these cases.

Interesting. <comments sent off list>

> No. There were, in fact, a number of other fundamental issues that 
> led to the selection of CGA-in-ND-options approach in SEND over 
> AH-enhanced-with-CGA. These issues had to do with the division of 
> work within a stack, the expressive power of policy entries, 
> co-existence with non-SEND devices, mismatch between provided and 
> expected models (e.g. number of parties), and so on.

Apologies, I'm not questioning CGA and it's use with SeND at all.

I'm questioning wider off-link, non-ND use of CGA, eg with Shim.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
QOTD:
 	The only easy way to tell a hamster from a gerbil is that the
 	gerbil has more dark meat.

Delivery-date: Mon, 03 Oct 2005 15:53:17 +0000
Date: Mon, 03 Oct 2005 18:53:18 +0300
From: Jari Arkko <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC:  [email-masked]
Subject: Re: addition of TLV to locator ID or locator ID set

Brian E Carpenter wrote:

> I meant to send this to the list and accidentally
> sent it only to Jason some days ago:
>
> Jason Schiller ([email-masked]) wrote:
>
>> Summary:  support for an additional TLV is required in order to allow 
>> for
>> a destination (sink) to signal to a source which links should be 
>> utilized
>> to carry traffic inbound to the destination (sink).
>>
>
> Jason, I understand your goal here and it is very reasonable.
>
> However, I would like to ask whether this policy-like information 
> should be
> signalled in-band with the locator set (which is host to host) or
> whether it should be signalled out of band as a policy mechanism, and in
> that case signalled site to site. I'm assuming that the real requirement
> is to apply site to site preferences.

This is a good discussion. Some of the design alternatives here
include placing the information in DNS, having the routers do
it, having the hosts do it, or some combination of these. I
would actually prefer seeing a rather host oriented approach
in terms of actually using this information. However, its very
clear that the hosts won't have the full network picture, can
not be configured with the necessary policy information and
have other problems in dealing with the whole problem. However,
it would seem that some kind of router control/advice
combined with host behaviour would be a good tradeoff.

--Jari

Delivery-date: Mon, 03 Oct 2005 15:51:21 +0000
Date: Mon, 03 Oct 2005 18:51:25 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  [email-masked]
Subject: Re: addition of TLV to locator ID or locator ID set

Erik Nordmark wrote:

>  - Perhaps automating this configuration (DHCP?) would be worth-while?

Or some more dynamic mechanism, such as ICMP Multihoming Advice
command (perhaps secured by SEND).

--Jari

Delivery-date: Mon, 03 Oct 2005 15:44:13 +0000
Date: Mon, 03 Oct 2005 18:44:20 +0300
From: Jari Arkko <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

> BTW, one question, is HBA a requirement for shim6?

I don't think we've finalized our design decisions yet,
but HBA is the working assumption, I think. Or HBA+CGA.
In any case, a protocol such as SHIM6 obviously needs to nail
down the specific mechanisms it uses, so if the working
assumption stays then yes, HBA will be a requirement.

--Jari

Delivery-date: Mon, 03 Oct 2005 15:42:46 +0000
Date: Mon, 03 Oct 2005 18:42:42 +0300
From: Jari Arkko <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

> Right, and the protocol we have for key data exchange is IKE.

Well... not really. I at least tend to think of security problems
as somewhat application specific. We've certainly tried on many
occasions to use an underlying IPsec/IKE security model to do
things beyond basic VPN. However, in my experience this
has most often failed. See http://www.arkko.com/publications/SWP03.pdf
for a discussion of some of these cases.

> At which point you may possibly just want to use IPSec AH to secure 
> the traffic. Would I be correct in thinking that only advantage CGA 
> for such off-link authentication would be saving packet-data overhead 
> of the AH header?

No. There were, in fact, a number of other fundamental issues that
led to the selection of CGA-in-ND-options approach in SEND over
AH-enhanced-with-CGA. These issues had to do with the
division of work within a stack, the expressive power of policy
entries, co-existence with non-SEND devices, mismatch between
provided and expected models (e.g. number of parties), and so
on.

--Jari

Delivery-date: Mon, 03 Oct 2005 15:31:57 +0000
Date: Mon, 03 Oct 2005 18:32:05 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked], shim6-wg <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

>> CGA simply ties a public key / certificate to an address. This key or 
>> certificate can then be used to authenticate further exchanges so an 
>> attacker can't successfully inject shim signalling.
>
>
> That's the same thing you could achieve with anonymous IPSec. (Though, 
> IPSec associates state with a 'security association' rather than 
> address, which could be more fine-grained than CGA). It's an anonymous 
> key either way, unless there is some other way to verify the 
> authenticity of a key and what it may be used for / who it is issued 
> for (who in terms of IP addresses). ,

This discussion is somewhat hard, because there are different
interpretations of what anonymous IPsec is. In some cases its
an anonymous encryption scheme which does nothing more than
prevent wholesale traffic interception. In some other cases its
a leap-of-faith scheme to establish a binding between an address
(or selectors) and a key. Or we could be talking about MOBIKE,
which enables the movement and multihoming of a tunnel
endpoint.

Nevertheless, as far as I know, there is no IPsec variant that
provides what CGA does, i.e., establish a secure relationship
from an address to a key. Or what HBA does, establish a secure
relationship between addresses. Anonymous IPsec can be made to
provide a secure relationship from a key to an address, but that's not
the same thing, because its not a bidirectional relationship. Anonymous
IPsec, as defined in draft-williams-btns-00.txt can be used to
lock keys and addresses together, but this can only be used in
a very limited manner as there's a DoS problem when someone
accidentally or maliciously locks an address that you would
need to use.

This is not to say that IPsec couldn't work for this. It can,
particularly in specific applications. For instance, MOBIKE
works because it deals only with VPN tunnel endpoints of an
established security association, and does not add any
means to grab someone else's traffic inside the moving
or multihoming tunnel.

--Jari

Delivery-date: Mon, 03 Oct 2005 15:31:41 +0000
Date: Mon, 3 Oct 2005 16:30:30 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Jari Arkko wrote:

> The answer to this question relates to how much dynamism we want in 
> the address sets. Also, there may be some feature interactions with 
> sites that want to employ both SEND and SHIM6.

Indeed. SeND and CGA seems very interesting for on-link 
authentication.

> Both need an exchange to assure the other party that things are OK, 
> e.g., we need to communicate the values (not just the key) used in 
> the hashing process.

Right, and the protocol we have for key data exchange is IKE.

At which point you may possibly just want to use IPSec AH to secure 
the traffic. Would I be correct in thinking that only advantage CGA 
for such off-link authentication would be saving packet-data overhead 
of the AH header?

> RFC 3971 is an example of a protocol that does this. This isn't 
> IKE. (But a lot of people confuse the use of public keys with 
> certified public keys, PKIs, and configured security. This isn't 
> the case for here, however.)

Right, even if you used CGA, you could still use CGA and use IKE for 
key data/parameters exchange.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
When you have to kill a man it costs nothing to be polite.
 		-- Winston Churchill, on formal declarations of war

Delivery-date: Mon, 03 Oct 2005 15:14:58 +0000
Date: Mon, 03 Oct 2005 18:14:57 +0300
From: Jari Arkko <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

> I'd have to ask: Why use CGA?

The answer to this question relates to how much dynamism we
want in the address sets. Also, there may be some feature interactions
with sites that want to employ both SEND and SHIM6.

> AFAICT, CGA was created specifically because relying on IPSec for 
> address assignment has bootstrap issues. Hence CGA and SeND.

CGAs were in fact initially developed for another purpose, namely
Mobile IPv6. They are usable in address ownership related tasks,
but to date their usage has been described for secure ND only.

> For modes relying on anonymously introduced public-key cryptography, 
> we won't have bootstrap issues here, so why not use standard IPSec? Is 
> it just to avoid the size of an AH header on each packet?
>
> How will you communicate the CGA parameters? Is shim to reinvent 
> portions of IKE in order to communicate public keys? Why not just use 
> IKE? IPSec is well-understood, widely implemented and deployed. Why 
> give ourselves the task of reinventing aspects of it?
>
> I can see some of the attractions of HBA, but using CGA beyond the 
> local-link is stretching it..

There isn't really anything that different in CGA and HBA at this level.
CGA allows dynamic changes. But both need no user input or config,
prior arrangement between parties, or trusted third parties.

Both need an exchange to assure the other party that things are
OK, e.g., we need to communicate the values (not just the key)
used in the hashing process.

RFC 3971 is an example of a protocol that does this. This isn't
IKE. (But a lot of people confuse the use of public keys with
certified public keys, PKIs, and configured security. This isn't
the case for here, however.)

--Jari

Delivery-date: Mon, 03 Oct 2005 14:46:14 +0000
Subject: [ot] [email-masked] reachability (Was: draft-ietf-shim6-proto-00.txt)
From: Jeroen Massar <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: shim6 <[email-masked]>
Organization: Unfix
Date: Mon, 03 Oct 2005 16:45:53 +0200

--=-1XIoL6J0wXJ4JUjNXl+M
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2005-10-03 at 07:24 -0700, Erik Nordmark wrote:
> The draft is currently up at=20
> <http://www.muada.com/drafts/draft-ietf-shim6-proto-00.txt>

/me reads ;)

> Thanks Iljitsch!
>=20
> I hope there is still time for folks to read this before Amsterdam.
>=20
> (FWIW: [email-masked] seem to have gone dead - I've submitted=20
> this several times starting on the 27th.)

In every case one has problems with ietf.org infrastructure, contact*:
  [email-masked]
You will directly receive a reply containing a ticket number.
This at least makes sure that your message is received.

IMHO [email-masked] is always very responsive.
Also note that several submissions being published every night since
that date.

Greets,
 Jeroen

* =3D as per http://www.ietf.org/secretariat.html

--=-1XIoL6J0wXJ4JUjNXl+M
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-1XIoL6J0wXJ4JUjNXl+M--

Delivery-date: Mon, 03 Oct 2005 14:24:37 +0000
Date: Mon, 03 Oct 2005 07:24:36 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: draft-ietf-shim6-proto-00.txt

The draft is currently up at 
<http://www.muada.com/drafts/draft-ietf-shim6-proto-00.txt>

Thanks Iljitsch!

I hope there is still time for folks to read this before Amsterdam.

(FWIW: [email-masked] seem to have gone dead - I've submitted 
this several times starting on the 27th.)

    Erik

Delivery-date: Mon, 03 Oct 2005 13:59:27 +0000
Date: Mon, 3 Oct 2005 14:58:43 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:

> i am not sure what you mean here, nut just for stating things 
> precisely, HBA do have globally assigned prefixes

Uh, ah. I didn't realise that. Who assigns them? And surely the point 
of HBA is that they can be locally assigned? (Or do you mean HBA's 
stand a very good chance of being globally /unique/?).

>> I had, in my mind, been considering that there would be a mechanism to 
>> allow the prefix set -> ULID mapping to change
>
> there is, the CGA part of the HBA/CGA hybrid addresses.

> That is why there are three flavors of addresses:
> - HBA that support a static set of addresses that cannot be changed during 
> the lifetime of an established communication (with the cost of a hash per 
> address)
> - CGA/HBA that support a stable prefix set and additional addresses that can 
> be added during the lifetime of the communications (the cost of the stable 
> addresses is a hash operation while the cost of a new address (out of the 
> initial set) is a public key operation)
> - CGA addresses, any addresses can be used with the cost of a public key 
> operation

I'd have to ask: Why use CGA?

AFAICT, CGA was created specifically because relying on IPSec for 
address assignment has bootstrap issues. Hence CGA and SeND.

For modes relying on anonymously introduced public-key cryptography, 
we won't have bootstrap issues here, so why not use standard IPSec? 
Is it just to avoid the size of an AH header on each packet?

How will you communicate the CGA parameters? Is shim to reinvent 
portions of IKE in order to communicate public keys? Why not just use 
IKE? IPSec is well-understood, widely implemented and deployed. Why 
give ourselves the task of reinventing aspects of it?

I can see some of the attractions of HBA, but using CGA beyond the 
local-link is stretching it..

(That's not to say a host that was configured with a key for CGA 
couldn't use the same public key for IPSec..)

> However, you should note that the public key used is included in 
> the hash that results in the interface identifier of the addresses

Ok.

>> fairly big cost in functionality. (Eg, what exactly would shim6 
>> using invariant HBAs offer over application layer remapping 
>> support?
>
> i am not sure i understand what you mean here... could you expand?

For me, the prime benefit of multihoming is not so much having 
multiple links but having number portability and the ability to 
easily transfer between providers[1]. Eg, shim'ing but having only 
one provider would be something I'd be interested in if it gave me 
portability. It's been a big reason for multihoming for two 
organisations I've worked with.

Without portability, you're left only with solving failure events 
amongst multihomed links. And I don't think you need a shim layer for 
this, personally.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
travel, n.:
 	Something that makes you feel like you're getting somewhere.

Delivery-date: Mon, 03 Oct 2005 13:18:25 +0000
Cc: shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Mon, 3 Oct 2005 15:18:45 +0200
To: Paul Jakma <[email-masked]>

El 03/10/2005, a las 14:10, Paul Jakma escribi=F3:

> On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:
>
>> well, hybrid CGA/HBA is required if you want that an established=20
>> communications can use a new prefix introduced to the site due for=20
>> instance, to renumbering. I guess that the need for this is at least=20=

>> debatable, since a renumbering event is expected to be not so=20
>> frequent compared to the expect lifetime of most established=20
>> communications. I guess that for most established communications, it=20=

>> is good enough to keep on using the remaining prefixes available, and=20=

>> then when a new communication is established to incorporate the new=20=

>> prefix available after renumbering. So i would say that the public=20
>> key will be needed in rare cases where extremely long lived=20
>> communications are required.
>
> Ok, sure. That could be an acceptable tradeoff. That's also the detail=20=

> I had been missing / not considered. That allowing the underlying=20
> prefix set to change significantly would not be allowed.
>
> Actually we can therefore end this discussion wrt=20
> Shim6-by-site-intermediary, because there are no more=20
> incompatibilities - simply be saying that the site-intermediary case=20=

> would have to use a globally assigned address prefix.

i am not sure what you mean here, nut just for stating things=20
precisely, HBA do have globally assigned prefixes

> That is what I had in mind, so:
>
> end-host shim6 -> uses a HBA for ULID.
>
> site shim6 ->
> 	 hosts are assigned ULIDs from a stable, invariant address =
range.
> 	 hosts just use regular IPv6 stacks and regular ways to
> 	   assign themselves IPv6 addresses

These could be HBA as well, just that someone else should create the=20
HBA set for the host e.g. the dhcp server could generate the hba set=20
for the legacy hosts

> 	 intermediary does shim6, 1:1 mapping.
>
> Both cases would use the shim6 mechanisms. The latter case would need=20=

> further thought regarding the ulid:locator(s) binding (providing proof=20=

> of its validity), which HBA would have provided (as per end-host).=20
> (One possibility would be that such a globally-assigned but=20
> non-globally routable prefix would also have a key set registered at=20=

> the point assignment, gets tricky - but the mechanism at could allow=20=

> for such. Probably difficult to solve without significant operational=20=

> considerations. :( )
>
>> I guess this depends about how do you define who... At this level,=20
>> who is the identifier and where is the locator, so the HBA/CGA=20
>> actually securely bind the who with the where This is exactly what=20
>> need to be protected, since the shim is separating the who form the=20=

>> where.
>
> Right.
>
>> I mean, currently, the relationship between the who and the where is=20=

>> the identity, since both are the IP address of the node. With the=20
>> shim, the locator and the id are separated, so what is needed from a=20=

>> security p.o.v. is to restore the security of that binding, which is=20=

>> exactly what is achieved with the CGA/HBA
>
> Well, that depends on 'security' really. But as your point below, I=20
> guess it does at least make it the same as existing IP, yes.
>
> Problem is, we intend to introduce something new, shim6 mechanisms. :)
>
> HBA does solve a lot of the spoofing issues though, yes - i understand=20=

> that now - if renumbering is left out.

>> right but current (non shim) communications are vulnerable to on path=20=

>> attackers, so this is no worst that today... the goal from a security=20=

>> perspective is that shim communications are as secure as non shim=20
>> communications
>
> Ok.
>
>>> HBA seems a way to detect quite fraudulent packets (invalid=20
>>> binding), it doesn't seem (to me) to be a way to assure a received=20=

>>> packet came from where the binding claims it did.
>>
>> just as today, right?
>
> Sure.
>
>> With HBA/CGA is the same, since in order to receive packets to the=20
>> claimed locator, you need to be the owner of the HBA set (i.e. being=20=

>> able to receive packets at the HBA addresses) or be an on path=20
>> attacker
>
> Right.
>
>>> C can, at a minimum, play havoc with any shim mapping on E relevant=20=

>>> to A,
>>
>> not sure what do you mean here... what kind of attack do you have in=20=

>> mind?
>>
>> I mean, shim communications protected by the CGA/HBA are susceptible=20=

>> to on path attackers as any non-shim communications
>
> I had, in my mind, been considering that there would be a mechanism to=20=

> allow the prefix set -> ULID mapping to change

there is, the CGA part of the HBA/CGA hybrid addresses.
That is why there are three flavors of addresses:
- HBA that support a static set of addresses that cannot be changed=20
during the lifetime of an established communication (with the cost of a=20=

hash per address)
- CGA/HBA that support a stable prefix set and additional addresses=20
that can be added during the lifetime of the communications (the cost=20
of the stable addresses is a hash operation while the cost of a new=20
address (out of the initial set) is a public key operation)
- CGA addresses, any addresses can be used with the cost of a public=20
key operation

>  (to support (partial-)?renumbering events). If that is not to be=20
> allowed, then indeed the attacks are minimal.
>
>> I think that the key point here is to understand the threats=20
>> introduced by the shim. The goal in not to provide extra security,=20
>> but to make things not worse that what are today in non-shim=20
>> communications.
>
>> because otherwise, anyone could claim that any identifier is located=20=

>> in any locator, which is clearly worst than what we have today
>
> Right, and HBA prevents such claims. I had failed to understand that.=20=

> I had thought (from the example in the draft which referred to using a=20=

> public key) that there would be a way to allow such claims to be made=20=

> (or at least, for an existing HBA mapping to change its verifiable=20
> mapping and claim a new mapping).

yes they are, see above.
However, you should note that the public key used is included in the=20
hash that results in the interface identifier of the addresses

>
> If that is not to be allowed, then everything is much simpler. But at=20=

> a fairly big cost in functionality. (Eg, what exactly would shim6=20
> using invariant HBAs offer over application layer remapping support?

i am not sure i understand what you mean here... could you expand?

regards, marcelo

Delivery-date: Mon, 03 Oct 2005 12:50:17 +0000
Date: Mon, 3 Oct 2005 13:49:25 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: [email-masked], shim6-wg <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, Iljitsch van Beijnum wrote:

> However, without HBA or CGA it would be possible to redirect 
> packets (assuming the shim is used) even in the presence of IPsec.

CGA would not make that impossible AIUI, it'd make it impossible to 
redirect an /existing/ shim state, AIUI (which is same as you'd get 
with IPSec).

HBA (a special case of CGA right?) makes it impossible by binding 
locator prefixes to ULIDs uniquely (ie permanently).

Right?

> CGA simply ties a public key / certificate to an address. This key 
> or certificate can then be used to authenticate further exchanges 
> so an attacker can't successfully inject shim signalling.

That's the same thing you could achieve with anonymous IPSec. 
(Though, IPSec associates state with a 'security association' rather 
than address, which could be more fine-grained than CGA). It's an 
anonymous key either way, unless there is some other way to verify 
the authenticity of a key and what it may be used for / who it is 
issued for (who in terms of IP addresses).

> can execute any valid signalling exchange. However, the HBA limits 
> the set of valid exchanges to the ones related to a prefix where 
> that prefix is one of the set for which there is a valid hash in 
> the interface identifier.

Ok.

>> if the only security is HBA and the shim protocol is stateless (without 
>> having to observe packets obviously).
>
> Obviously all signalling will use cookies so blind injection attacks 
> shouldn't be an issue.

Ok, in which case you'll need a handshake before you accept the 
cookie as valid, to establish two-way communication (two-way at shim6 
level, each direction might use a different path).

> Suppose C now initates a rehoming. C would also have to be present 
> at the new address A' in order for E to accept the change. And A' 
> must be an address that belongs to A because otherwise A wouldn't 
> have included the prefix in question in its HBA.

Right.

Obviously, if renumbering were to be allowed, then C could redirect 
the mapping completely away from A (the only part supposed to be 
using that HBA).

The security issues are quite interesting. :)

> I suppose this attack might be useful for C if C can only be a man 
> in the middle between A and E for a short time, but be a man in the 
> middle between A' and E for a longer period. As long as C keeps the 
> A' - E association alive, A is going to have a hard time connecting 
> to E using A - E.

Right.

It does preclude renumbering though, which is an interesting 
(unfortunate?) consequence.

Sorry for being so annoying btw, I just can't help questioning things 
as a means to gaining understanding.. ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
party, n.:
 	A gathering where you meet people who drink
 	so much you can't even remember their names.

Delivery-date: Mon, 03 Oct 2005 12:36:30 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Mon, 3 Oct 2005 14:36:08 +0200
To: Paul Jakma <[email-masked]>

On 3-okt-2005, at 14:10, Paul Jakma wrote:

> end-host shim6 -> uses a HBA for ULID.

> site shim6 ->
>      hosts are assigned ULIDs from a stable, invariant address range.
>      hosts just use regular IPv6 stacks and regular ways to
>        assign themselves IPv6 addresses
>      intermediary does shim6, 1:1 mapping.

> Both cases would use the shim6 mechanisms. The latter case would  
> need further thought regarding the ulid:locator(s) binding  
> (providing proof of its validity), which HBA would have provided  
> (as per end-host). (One possibility would be that such a globally- 
> assigned but non-globally routable prefix would also have a key set  
> registered at the point assignment, gets tricky - but the mechanism  
> at could allow for such. Probably difficult to solve without  
> significant operational considerations. :( )

Well, one way to do something HBA-like for the second case would be  
to insert the hash in bits 8 - 47 rather than 64 - 127. That way,  
unique site locals can easily be reused here. Of course 40 bits isn't  
all that strong, but it's probably good enough to thwart casual attacks.

Another approach is to put the keys in the DNS.

But in any event, using unreachable ULIDs has two important  
repercussions:

- the communication is no longer backward compatible
- shim state must be created before the communication can start

However, I think we need to solve this because our solution would be  
incomplete if we can't recover from the ULP choosing an ULID that  
happens to be unreachable.

Delivery-date: Mon, 03 Oct 2005 12:11:25 +0000
Date: Mon, 3 Oct 2005 13:10:14 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:

> well, hybrid CGA/HBA is required if you want that an established 
> communications can use a new prefix introduced to the site due for 
> instance, to renumbering. I guess that the need for this is at 
> least debatable, since a renumbering event is expected to be not so 
> frequent compared to the expect lifetime of most established 
> communications. I guess that for most established communications, 
> it is good enough to keep on using the remaining prefixes 
> available, and then when a new communication is established to 
> incorporate the new prefix available after renumbering. So i would 
> say that the public key will be needed in rare cases where 
> extremely long lived communications are required.

Ok, sure. That could be an acceptable tradeoff. That's also the 
detail I had been missing / not considered. That allowing the 
underlying prefix set to change significantly would not be allowed.

Actually we can therefore end this discussion wrt 
Shim6-by-site-intermediary, because there are no more 
incompatibilities - simply be saying that the site-intermediary case 
would have to use a globally assigned address prefix. That is what I 
had in mind, so:

end-host shim6 -> uses a HBA for ULID.

site shim6 ->
 	 hosts are assigned ULIDs from a stable, invariant address range.
 	 hosts just use regular IPv6 stacks and regular ways to
 	   assign themselves IPv6 addresses
 	 intermediary does shim6, 1:1 mapping.

Both cases would use the shim6 mechanisms. The latter case would need 
further thought regarding the ulid:locator(s) binding (providing 
proof of its validity), which HBA would have provided (as per 
end-host). (One possibility would be that such a globally-assigned 
but non-globally routable prefix would also have a key set registered 
at the point assignment, gets tricky - but the mechanism at could 
allow for such. Probably difficult to solve without significant 
operational considerations. :( )

> I guess this depends about how do you define who... At this level, 
> who is the identifier and where is the locator, so the HBA/CGA 
> actually securely bind the who with the where This is exactly what 
> need to be protected, since the shim is separating the who form the 
> where.

Right.

> I mean, currently, the relationship between the who and the where 
> is the identity, since both are the IP address of the node. With 
> the shim, the locator and the id are separated, so what is needed 
> from a security p.o.v. is to restore the security of that binding, 
> which is exactly what is achieved with the CGA/HBA

Well, that depends on 'security' really. But as your point below, I 
guess it does at least make it the same as existing IP, yes.

Problem is, we intend to introduce something new, shim6 mechanisms. 
:)

HBA does solve a lot of the spoofing issues though, yes - i 
understand that now - if renumbering is left out.

> right but current (non shim) communications are vulnerable to on 
> path attackers, so this is no worst that today... the goal from a 
> security perspective is that shim communications are as secure as 
> non shim communications

Ok.

>> 
>> HBA seems a way to detect quite fraudulent packets (invalid binding), it 
>> doesn't seem (to me) to be a way to assure a received packet came from 
>> where the binding claims it did.
>
> just as today, right?

Sure.

> With HBA/CGA is the same, since in order to receive packets to the 
> claimed locator, you need to be the owner of the HBA set (i.e. 
> being able to receive packets at the HBA addresses) or be an on 
> path attacker

Right.

>> C can, at a minimum, play havoc with any shim mapping on E relevant to A,
>
> not sure what do you mean here... what kind of attack do you have in mind?
>
> I mean, shim communications protected by the CGA/HBA are 
> susceptible to on path attackers as any non-shim communications

I had, in my mind, been considering that there would be a mechanism 
to allow the prefix set -> ULID mapping to change (to support 
(partial-)?renumbering events). If that is not to be allowed, then 
indeed the attacks are minimal.

> I think that the key point here is to understand the threats 
> introduced by the shim. The goal in not to provide extra security, 
> but to make things not worse that what are today in non-shim 
> communications.

> because otherwise, anyone could claim that any identifier is 
> located in any locator, which is clearly worst than what we have 
> today

Right, and HBA prevents such claims. I had failed to understand that. 
I had thought (from the example in the draft which referred to using 
a public key) that there would be a way to allow such claims to be 
made (or at least, for an existing HBA mapping to change its 
verifiable mapping and claim a new mapping).

If that is not to be allowed, then everything is much simpler. But at 
a fairly big cost in functionality. (Eg, what exactly would shim6 
using invariant HBAs offer over application layer remapping support? 
(another thread perhaps?)).

> I mean, if the shim allows to freely bind any id to any locator, 
> then any communication could be redirected to any locator that any 
> attacker wants, which is way more vulnerable than current attacks 
> to the routing system.

Indeed.

Thanks for perserving in explaining the intended use of HBA to me. 
Though, it does for me open some further questions.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
When you dig another out of trouble, you've got a place to bury your own.

Delivery-date: Mon, 03 Oct 2005 12:10:55 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Mon, 3 Oct 2005 14:10:09 +0200
To: Paul Jakma <[email-masked]>

In addition to what Marcelo posted...

On 3-okt-2005, at 10:42, Paul Jakma wrote:

>> HBA addresses are bound to a given prefix set i.e. the addresses  
>> of a given HBA set are bound together and this cannot be easily  
>> forged. In the same way, the CGA is bound to a public key and  
>> cannot be easily forged.

> Sure, so it proves the packet was constructed correctly, at least  
> the association of the outer locator prefix to the inner ULID. This  
> doesn't prove anything about who sent the packet though, does it?

Right. With HBA, the ONLY thing that's protected is the set of  
prefixes that host using the HBA address is connected to. (Obviously  
a host can also add prefixes to the HBA that it's not connected to,  
but the point is that third parties can't.)

Along with a verification procedure, this makes it possible to  
authenticate the locator set / identifier relationship.

> It seems vulnerable to injection attacks (unless you assume routing  
> is secured in some way, eg RPF everywhere, but that still leaves a  
> an attacker who is on-link or MITM able to inject packets. Further,  
> operational experience shows this to be a dangerous assumption to  
> rely on).

> HBA seems a way to detect quite fraudulent packets (invalid  
> binding), it doesn't seem (to me) to be a way to assure a received  
> packet came from where the binding claims it did.

It's still entirely possible to inject all kinds of falsified  
packets. HBA and CGA aren't general purpose security mechanisms: if  
this is what you need, use IPsec.

However, without HBA or CGA it would be possible to redirect packets  
(assuming the shim is used) even in the presence of IPsec.

CGA simply ties a public key / certificate to an address. This key or  
certificate can then be used to authenticate further exchanges so an  
attacker can't successfully inject shim signalling.

With HBA, the shim signalling itself isn't protected: an attacker can  
execute any valid signalling exchange. However, the HBA limits the  
set of valid exchanges to the ones related to a prefix where that  
prefix is one of the set for which there is a valid hash in the  
interface identifier.

Now if the attacker has control over all these prefixes, the  
communication is at the mercy of the attacker. Even if the attacker  
can only observe packets flowing to/from the initial address and  
inject spoofed packets of his own, that's probably enough to make  
successful HBA-based shim signalling impossible. But the attacker  
can't do anything that he wouldn't be able to do if the shim wasn't  
there.

>> while it does exists in oportunistic IPSec. Actually, the nice  
>> thing about CGA/HBA is that they do provide a quite continuos  
>> protection and don't need to trust in the information exchanged  
>> during the initial contact, preventing the so-called future or  
>> time shifted attacks

> I'm not quite sure that's true:

> A-----B D ---E
>       | |
>      -----
>       |
>       C

> For whatever operational reasons C is able to send packets with the  
> same source prefix as A, it /might/ also able to able to observe  
> the packets sent by E to A.

> C can, at a minimum, play havoc with any shim mapping on E relevant  
> to A,

Yes, it can inject falsified shim signalling packets that make the  
real shim signalling derail.

> if the only security is HBA and the shim protocol is stateless  
> (without having to observe packets obviously).

Obviously all signalling will use cookies so blind injection attacks  
shouldn't be an issue.

> If the shim protocol is not stateless, eg through use of some  
> sequence number, then it can (without observation) possibly deny A  
> from speaking to E by setting up shim6 negotiation in advance of A  
> doing so (A's shim6 control packets then might be rejected, due to  
> wrong state) if E assumes that for a given valid HBA future state  
> will match.

So C would assume A's address and start communicating with E. C would  
then have to block traffic from E to A, or A would send RSTs or  
similar. So C would have to be a man in the middle.

Suppose C now initates a rehoming. C would also have to be present at  
the new address A' in order for E to accept the change. And A' must  
be an address that belongs to A because otherwise A wouldn't have  
included the prefix in question in its HBA.

I suppose this attack might be useful for C if C can only be a man in  
the middle between A and E for a short time, but be a man in the  
middle between A' and E for a longer period. As long as C keeps the  
A' - E association alive, A is going to have a hard time connecting  
to E using A - E.

> I don't see what prevents an attacker constructing the same HBA.

But ONLY the same HBA or an unrelated one: NOT one that has the same  
interface identifier with a different underlying prefix set (not  
without 2^50 or so tries). It's like being able to create a copy of a  
passport without being able to change the photo. Since in our case  
the "photo" doesn't allow for ambiguity this makes the "passport"  
useless for anyone but the real holder.

Delivery-date: Mon, 03 Oct 2005 09:47:03 +0000
Cc: shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Mon, 3 Oct 2005 11:47:00 +0200
To: Paul Jakma <[email-masked]>

El 03/10/2005, a las 10:42, Paul Jakma escribi=F3:

> On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:
>
>> there is no public key in HBA... there is public key in CGA though=20
>> (and in hybrid CGA/HBA)
>
> Hybrid being required to support renumbering events, right?
>

well, hybrid CGA/HBA is required if you want that an established=20
communications can use a new prefix introduced to the site due for=20
instance, to renumbering.
I guess that the need for this is at least debatable, since a=20
renumbering event is expected to be not so frequent compared to the=20
expect lifetime of most established communications.
I guess that for most established communications, it is good enough to=20=

keep on using the remaining prefixes available, and then when a new=20
communication is established to incorporate the new prefix available=20
after renumbering. So i would say that the public key will be needed in=20=

rare cases where extremely long lived communications are required.

>> However there is no security issues with CGA public key distribution=20=

>> because the CGA is intrinsically bound to the public key, so it is=20
>> extrmely hard to find a different public key that is bound to a given=20=

>> CGA
>
> Sure.
>
>> the HBA addresses are intrinsically bound to the prefix set, so there=20=

>> is no leap of faith involved in the usage of HBA (nor in CGA) as=20
>> opposed to opportunistic IPSec
>>
>> HBA addresses are bound to a given prefix set i.e. the addresses of a=20=

>> given HBA set are bound together and this cannot be easily forged. In=20=

>> the same way, the CGA is bound to a public key and cannot be easily=20=

>> forged.
>
> Sure, so it proves the packet was constructed correctly, at least the=20=

> association of the outer locator prefix to the inner ULID. This=20
> doesn't prove anything about who sent the packet though, does it?
>

I guess this depends about how do you define who...
At this level, who is the identifier and where is the locator, so the=20
HBA/CGA actually securely bind the who with the where
This is exactly what need to be protected, since the shim is separating=20=

the who form the where. I mean, currently, the relationship between the=20=

who and the where is the identity, since both are the IP address of the=20=

node.
With the shim, the locator and the id are separated, so what is needed=20=

from a security p.o.v. is to restore the security of that binding,=20
which is exactly what is achieved with the CGA/HBA

> It seems vulnerable to injection attacks (unless you assume routing is=20=

> secured in some way, eg RPF everywhere, but that still leaves a an=20
> attacker who is on-link or MITM able to inject packets. Further,=20
> operational experience shows this to be a dangerous assumption to rely=20=

> on).

right but current (non shim) communications are vulnerable to on path=20
attackers, so this is no worst that today...
the goal from a security perspective is that shim communications are as=20=

secure as non shim communications

>
> HBA seems a way to detect quite fraudulent packets (invalid binding),=20=

> it doesn't seem (to me) to be a way to assure a received packet came=20=

> from where the binding claims it did.

just as today, right?

Anyobe can send form any IP address as long as there are no ingress=20
filters, but if you want to receive packets to the calimed address, you=20=

need to be at the correct topological location (i.e. be the owner of=20
the address) or be on the path.

With HBA/CGA is the same, since in order to receive packets to the=20
claimed locator, you need to be the owner of the HBA set (i.e. being=20
able to receive packets at the HBA addresses) or be an on path attacker

>
>> As i mentioned above, there is no leap of faith in HBA/CGA security,
>
>> while it does exists in oportunistic IPSec. Actually, the nice thing=20=

>> about CGA/HBA is that they do provide a quite continuos protection=20
>> and don't need to trust in the information exchanged during the=20
>> initial contact, preventing the so-called future or time shifted=20
>> attacks
>
> I'm not quite sure that's true:
>
>
> A-----B D ---E
>       | |
>      -----
>       |
>       C
>
> For whatever operational reasons C is able to send packets with the=20
> same source prefix as A, it /might/ also able to able to observe the=20=

> packets sent by E to A.
>
> C can, at a minimum, play havoc with any shim mapping on E relevant to=20=

> A,

not sure what do you mean here... what kind of attack do you have in=20
mind?

I mean, shim communications protected by the CGA/HBA are susceptible to=20=

on path attackers as any non-shim communications

>  if the only security is HBA and the shim protocol is stateless=20
> (without having to observe packets obviously). If the shim protocol is=20=

> not stateless, eg through use of some sequence number, then it can=20
> (without observation) possibly deny A from speaking to E by setting up=20=

> shim6 negotiation in advance of A doing so (A's shim6 control packets=20=

> then might be rejected, due to wrong state) if E assumes that for a=20
> given valid HBA future state will match. With observation, C can=20
> likely play further havoc.
>
> Attacks requiring no observation likely would work regardless where C=20=

> is located..
>
> Obviously, we don't know yet what the shim6 protocol will be. But I=20
> don't think it can assume very much about security just because HBA=20
> checks out..

I think that the key point here is to understand the threats introduced=20=

by the shim. The goal in not to provide extra security, but to make=20
things not worse that what are today in non-shim communications.

>
>> The problem is not key exchange, is the binding between the=20
>> identifier and the key. for example you could use the key of the CGA=20=

>> in IPSec, (actually, HIP is basically what it does) and we could use=20=

>> AH and ESP formats here for securing the shim protocol, no problem=20
>> with that. The point is how do we make sure that the key used in=20
>> IPSec corresponds to the identifier we are using and not to an=20
>> attacker
>
> I don't see what prevents an attacker constructing the same HBA.
>

it prevents that an attacker to freely associate any locator to any=20
identifer, as described in the threats draft

> If you rely solely on HBA validation then Shim would be vulnerable to=20=

> injection attacks. If you add further state to the Shim protocol to=20
> defeat blind injection attacks, then you'll be open to same anonymous=20=

> state DoSes as anonymous IPSec. (In which case you might as well have=20=

> used IPSec).
>
>> right, how do you bind the key used in IPSec with the ULP identifier=20=

>> used in the shim?
>
> Well, why is this required exactly?

because otherwise, anyone could claim that any identifier is located in=20=

any locator, which is clearly worst than what we have today

> I don't think it provides that much security (just a modicum of=20
> anti-spoofing protection).
>
>> how to perform the binding between the ULP identifier and the key=20
>> used in IPSec
>
> You don't have a secure binding though, unless you assume IPv6 routing=20=

> is to be completely secured before shim6 deployment and made immune to=20=

> injection (unlikely).
>

Well, actually, today, if you want that packets addressed to a given=20
address A are delivered to address X you need to tamper the routing=20
system. This may not be so difficult, but it is definitely not=20
available to any user.

I mean, if the shim allows to freely bind any id to any locator, then=20
any communication could be redirected to any locator that any attacker=20=

wants, which is way more vulnerable than current attacks to the routing=20=

system.

regards, marcelo

> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> UFOs are for real: the Air Force doesn't exist.
>

Delivery-date: Mon, 03 Oct 2005 08:43:28 +0000
Date: Mon, 3 Oct 2005 09:42:00 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:

> there is no public key in HBA... there is public key in CGA though 
> (and in hybrid CGA/HBA)

Hybrid being required to support renumbering events, right?

> However there is no security issues with CGA public key 
> distribution because the CGA is intrinsically bound to the public 
> key, so it is extrmely hard to find a different public key that is 
> bound to a given CGA

Sure.

> the HBA addresses are intrinsically bound to the prefix set, so 
> there is no leap of faith involved in the usage of HBA (nor in CGA) 
> as opposed to opportunistic IPSec
>
> HBA addresses are bound to a given prefix set i.e. the addresses of 
> a given HBA set are bound together and this cannot be easily 
> forged. In the same way, the CGA is bound to a public key and 
> cannot be easily forged.

Sure, so it proves the packet was constructed correctly, at least the 
association of the outer locator prefix to the inner ULID. This 
doesn't prove anything about who sent the packet though, does it?

It seems vulnerable to injection attacks (unless you assume routing 
is secured in some way, eg RPF everywhere, but that still leaves a an 
attacker who is on-link or MITM able to inject packets. Further, 
operational experience shows this to be a dangerous assumption to 
rely on).

HBA seems a way to detect quite fraudulent packets (invalid binding), 
it doesn't seem (to me) to be a way to assure a received packet came 
from where the binding claims it did.

> As i mentioned above, there is no leap of faith in HBA/CGA 
> security,

> while it does exists in oportunistic IPSec. Actually, the nice 
> thing about CGA/HBA is that they do provide a quite continuos 
> protection and don't need to trust in the information exchanged 
> during the initial contact, preventing the so-called future or time 
> shifted attacks

I'm not quite sure that's true:

A-----B D ---E
       | |
      -----
       |
       C

For whatever operational reasons C is able to send packets with the 
same source prefix as A, it /might/ also able to able to observe the 
packets sent by E to A.

C can, at a minimum, play havoc with any shim mapping on E relevant 
to A, if the only security is HBA and the shim protocol is stateless 
(without having to observe packets obviously). If the shim protocol 
is not stateless, eg through use of some sequence number, then it can 
(without observation) possibly deny A from speaking to E by setting 
up shim6 negotiation in advance of A doing so (A's shim6 control 
packets then might be rejected, due to wrong state) if E assumes that 
for a given valid HBA future state will match. With observation, C 
can likely play further havoc.

Attacks requiring no observation likely would work regardless where C 
is located..

Obviously, we don't know yet what the shim6 protocol will be. But I 
don't think it can assume very much about security just because HBA 
checks out..

> The problem is not key exchange, is the binding between the 
> identifier and the key. for example you could use the key of the 
> CGA in IPSec, (actually, HIP is basically what it does) and we 
> could use AH and ESP formats here for securing the shim protocol, 
> no problem with that. The point is how do we make sure that the key 
> used in IPSec corresponds to the identifier we are using and not to 
> an attacker

I don't see what prevents an attacker constructing the same HBA.

If you rely solely on HBA validation then Shim would be vulnerable to 
injection attacks. If you add further state to the Shim protocol to 
defeat blind injection attacks, then you'll be open to same anonymous 
state DoSes as anonymous IPSec. (In which case you might as well have 
used IPSec).

> right, how do you bind the key used in IPSec with the ULP 
> identifier used in the shim?

Well, why is this required exactly? I don't think it provides that 
much security (just a modicum of anti-spoofing protection).

> how to perform the binding between the ULP identifier and the key 
> used in IPSec

You don't have a secure binding though, unless you assume IPv6 
routing is to be completely secured before shim6 deployment and made 
immune to injection (unlikely).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
UFOs are for real: the Air Force doesn't exist.

Delivery-date: Mon, 03 Oct 2005 07:04:37 +0000
Cc: Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Sun, 2 Oct 2005 20:02:25 +0200
To: [email-masked], shim6-wg <[email-masked]>

El 02/10/2005, a las 17:59, Paul Jakma escribi=F3:

> On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:
>
>> IMHO, what would be not so hard to support would be that source=20
>> address prefixes get rewritten by the exit routers as long as the the=20=

>> security stuff remains end to end i.e. the hosts are the ones that=20
>> define the HBA/CGA sets and perform the security validation. That is=20=

>> basically offloading the source address selection to the router, but=20=

>> the remining parts of the shim are still in the hosts.
>
> That depends I guess on whether the HBA stuff tries to use more than=20=

> the 64bits of lower-order address space reserved for the host. If it=20=

> confined itself to that, it could work. If HBA wants to affect the=20
> higher order 64 bits, that would have implications for how to assign=20=

> such addresses.
>
> The HBA draft seems to suggest it confines itself to the 'interface=20
> identifier' though. (In which case, you just need a way to make the=20
> available-prefixes known to the hosts, to allow them to construct the=20=

> HBA identifier).
>

exactly

>> The problem here is how do you bind the key that is used in IPSec=20
>> with the identifier used.
>
>> If you don't provide a security binding, then an atacker can provide=20=

>> its own key and bind it to the victim's identifier, so no good.
>
>> The options to provide a secure binding are:
>> - a third trusted party i.e. PKI
>> - create the identifer so that it intrinsically contains key=20
>> information i.e. CGA/HBA
>>
>> because of the deployment issues, the second option seems more=20
>> attractive
>
> But you still have the issue of distributing the HBA public key, no?

there is no public key in HBA...
there is public key in CGA though (and in hybrid CGA/HBA)

However there is no security issues with CGA public key distribution=20
because the CGA is intrinsically bound to the public key, so it is=20
extrmely hard to find a different public key that is bound to a given=20
CGA

>  Otherwise the only thing HBA can prove is that the /first/ host which=20=

> communicated with you using some HBA address does not have its=20
> addresses subverted, right?

I think no

the HBA addresses are intrinsically bound to the prefix set, so there=20
is no leap of faith involved in the usage of HBA (nor in CGA) as=20
opposed to opportunistic IPSec

HBA addresses are bound to a given prefix set i.e. the addresses of a=20
given HBA set are bound together and this cannot be easily forged.
In the same way, the CGA is bound to a public key and cannot be easily=20=

forged.

>  Further, you will have to put a limit on how long a host remembers=20
> state (or, on the number of remote HBA hosts it may keep state for).=20=

> Once that state goes, so the window opens up for the HBA concerned to=20=

> be redirected, surely?
>
> There's no difference between that and anonymous IPSec, is there?
>

As i mentioned above, there is no leap of faith in HBA/CGA security,=20
while it does exists in oportunistic IPSec. Actually, the nice thing=20
about CGA/HBA is that they do provide a quite continuos protection and=20=

don't need to trust in the information exchanged during the initial=20
contact, preventing the so-called future or time shifted attacks

> IPSec however was designed to be able to be extensible and cope with=20=

> lots of different algorithms and key exchange schemas. You'd have to=20=

> reinvent all that to make HBA cope, plus you're limited to 128 bits of=20=

> information, if you want to use only the IPv6 address as the=20
> identifier. (what about replay attacks? :) ).
>

The problem is not key exchange, is the binding between the identifier=20=

and the key. for example you could use the key of the CGA in IPSec,=20
(actually, HIP is basically what it does) and we could use AH and ESP=20
formats here for securing the shim protocol, no problem with that. The=20=

point is how do we make sure that the key used in IPSec corresponds to=20=

the identifier we are using and not to an attacker

> Way I see it, as long as Shim state changes can not be effected with=20=

> ordinary shimmed packets, as long as state changes (eg,=20
> addition/removal of locators) can only be signaled via some side-band=20=

> Shim protocol[1] then you only need to secure that side-band. IPSec=20
> (the standardised, deployed and agreed on IETF security protocol for=20=

> IP..) will do fine for that and provide security ranging from=20
> anonymous to more trustworthy schemes.
>

right, how do you bind the key used in IPSec with the ULP identifier=20
used in the shim?

> Mind you, I still don't really fully grok HBA - what critical detail=20=

> am i missing?
>

how to perform the binding between the ULP identifier and the key used=20=

in IPSec

Regards, marcelo

>> regards, marcelo
>
> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> Goda's Truism:
> 	By the time you get to the point where you can make ends meet,
> 	somebody moves the ends.
>

Delivery-date: Sun, 02 Oct 2005 16:00:28 +0000
Date: Sun, 2 Oct 2005 16:59:17 +0100 (IST)
From: Paul Jakma <[email-masked]>
Reply-To: shim6-wg <[email-masked]>, [email-masked]
To: marcelo bagnulo braun <[email-masked]>
cc: Erik Nordmark <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:

> IMHO, what would be not so hard to support would be that source 
> address prefixes get rewritten by the exit routers as long as the 
> the security stuff remains end to end i.e. the hosts are the ones 
> that define the HBA/CGA sets and perform the security validation. 
> That is basically offloading the source address selection to the 
> router, but the remining parts of the shim are still in the hosts.

That depends I guess on whether the HBA stuff tries to use more than 
the 64bits of lower-order address space reserved for the host. If it 
confined itself to that, it could work. If HBA wants to affect the 
higher order 64 bits, that would have implications for how to assign 
such addresses.

The HBA draft seems to suggest it confines itself to the 'interface 
identifier' though. (In which case, you just need a way to make the 
available-prefixes known to the hosts, to allow them to construct the 
HBA identifier).

> The problem here is how do you bind the key that is used in IPSec with the 
> identifier used.

> If you don't provide a security binding, then an atacker can provide its own 
> key and bind it to the victim's identifier, so no good.

> The options to provide a secure binding are:
> - a third trusted party i.e. PKI
> - create the identifer so that it intrinsically contains key information i.e. 
> CGA/HBA
>
> because of the deployment issues, the second option seems more attractive

But you still have the issue of distributing the HBA public key, no? 
Otherwise the only thing HBA can prove is that the /first/ host which 
communicated with you using some HBA address does not have its 
addresses subverted, right? Further, you will have to put a limit on 
how long a host remembers state (or, on the number of remote HBA 
hosts it may keep state for). Once that state goes, so the window 
opens up for the HBA concerned to be redirected, surely?

There's no difference between that and anonymous IPSec, is there?

IPSec however was designed to be able to be extensible and cope with 
lots of different algorithms and key exchange schemas. You'd have to 
reinvent all that to make HBA cope, plus you're limited to 128 bits 
of information, if you want to use only the IPv6 address as the 
identifier. (what about replay attacks? :) ).

Way I see it, as long as Shim state changes can not be effected with 
ordinary shimmed packets, as long as state changes (eg, 
addition/removal of locators) can only be signaled via some side-band 
Shim protocol[1] then you only need to secure that side-band. IPSec 
(the standardised, deployed and agreed on IETF security protocol for 
IP..) will do fine for that and provide security ranging from 
anonymous to more trustworthy schemes.

Mind you, I still don't really fully grok HBA - what critical detail 
am i missing?

> regards, marcelo

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Goda's Truism:
 	By the time you get to the point where you can make ends meet,
 	somebody moves the ends.

Delivery-date: Sun, 02 Oct 2005 08:57:16 +0000
Cc: Erik Nordmark <[email-masked]>, Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Sun, 2 Oct 2005 10:46:40 +0200
To: Paul Jakma <[email-masked]>

El 30/09/2005, a las 22:16, Paul Jakma escribi=F3:

> On Thu, 29 Sep 2005, Erik Nordmark wrote:
>
>> How does the host get an IPv6 address assigned that has the right=20
>> low-order bits so that the HBA stuff on the remote shim/proxy can=20
>> prove (using HBA) to the peer that it owns the IPv6 address hence is=20=

>> allowed to redirect it?
>
> I don't know. I'm not terribly familiar with HBA. Marcelo seems to=20
> think it's possible.
>

IMHO, what would be not so hard to support would be that source address=20=

prefixes get rewritten by the exit routers as long as the the security=20=

stuff remains end to end i.e. the hosts are the ones that define the=20
HBA/CGA sets and perform the security validation.
That is basically offloading the source address selection to the=20
router, but the remining parts of the shim are  still in the hosts.

doing proxy shim for legacy hosts is much more complex, i.e. letting a=20=

proxy box to provide shim capabilities to a legacy host

> BTW, one question, is HBA a requirement for shim6?
>

as is see it, HBA are not a requirement but so far they seem to provide=20=

the security protection required
CGAs can also provide the security required, supporting additional=20
features with a higher computation cost.
As HBAs are defined as an extension to CGAs, then supporting both of=20
them would not be complex

> Other possibilities include simply securing the side-band shim6=20
> protocol (using, eg, anonymous IPSec) and disallowing any=20
> locator<->ULID (do i have the jargon correct?) state changes to occur=20=

> other than through the secured side-band.
>
> Then you wouldn't need to try stuff security state into an address.
>

The problem here is how do you bind the key that is used in IPSec with=20=

the identifier used.
If you don't provide a security binding, then an atacker can provide=20
its own key and bind it to the victim's identifier, so no good.
The options to provide a secure binding are:
- a third trusted party i.e. PKI
- create the identifer so that it intrinsically contains key=20
information i.e. CGA/HBA

because of the deployment issues, the second option seems more=20
attractive

regards, marcelo

>> destination locators to be changed). Thus if the shim proxy wants to=20=

>> handle this, it needs to first do a 1:1 IPv6 NAT where the proxy has=20=

>> created the HBA/CGA addresses for the host.
>
> It'd have to be a 1:1 NAT yes.
>
>> One could envision having DHCPv6 be shim aware so that when the hosts=20=

>> asks DHCP for an address, the DHCP server would interact with the=20
>> shim proxy so that the addresses are from a HBA or CGA set. In that=20=

>> case one wouldn't need the 1:1 IPv6 NAT in the shim proxy.
>
> Hmm, possible I guess.
>
>>   Erik
>
> regards,
> --=20
> Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
> Fortune:
> Liar, n.:
> 	A lawyer with a roving commission.
> 		-- Ambrose Bierce, "The Devil's Dictionary"
>

Delivery-date: Sat, 01 Oct 2005 01:21:02 +0000
Date: Fri, 30 Sep 2005 18:18:46 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: source address rewriting and shim6 proxies

marcelo bagnulo braun wrote:

> but this would mean that you would be accepting packets with any source 
> address? wouldn't be some serious security issues there?

Depends how hard it would be to guess the context tag. Only nodes on the 
path between A and B would know the context tag that B told A to use. 
And those nodes can use A's source addresses even if there is ingress 
filtering, since they are on the path.

Oh - doing router rewriting of the source address presumably implies 
that every data packet (even before a locator switch) have to carry a 
context tag, since the router can change the source locator on any packet.

   Erik