Subject: Re: Detailed approaches for demux
From: Steven Blake <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: shim6 <[email-masked]>
Date: Sat, 30 Apr 2005 15:54:08 -0400

On Sat, 2005-04-30 at 11:09 +0200, marcelo bagnulo braun wrote:

[snip]

> Demux at the receiver side is performed based on (flow label, src, dst)
> 
> The problem is what happens when a host run out of available flow label 
> values and need to start repeating. Note well that this happens when 
> the host has 1.048.576 (2^20) simultaneous communications.
> 
> If a repeated value is used in a communication with a different node, 
> then no problem, since the addresses will never collide.
> 
> So, the first measure to avoid problems is to avoid re-using flow label 
> values for communications with the same host whenever is possible.
> However, this is not always possible because the initiator may not be 
> aware that two communications are established with the same node.

Ignoring shim6 for a moment: a host that may have more than 2^20 active
connections can generate additional addresses (e.g., by synthesizing
additional IIDs) on an interface, and avoid ever having two or more
active flows sharing the same <S, Fl> tuple.

> So, the problem occurs when the same value is used for the same host.
> This may occur because the initiator may not be aware that two 
> different addresses belong to the same receiver.
> For example, consider the following case:
> I establishes a communication with R1 using S1 as source address and 
> assigns the flow label value f1.
> Next, I runs out of flow label values, and need to start repeating 
> values.
> At this point, I establishes a communication with R2 using S2.
> Since the Destination address R2 has not been previously used, I has no 
> means to know that is the same host, so I assigns the flow label value 
> f1.
> When the SHIM contexts are established for each of the communications, 
> the resulting contexts are:
> 
> SHIM context for the first communication:
> ULIDs: I1,R1
> Flow Label: f1
> Locator set for I1: I1,...,In (or a subset)
> Locator set for R1: R1,...,Rj (or a subset)
> 
> SHIM context for the second communication:
> ULIDs: I2,R2
> Flow Label: f1
> Locator set for I2: I1,...,In (or a subset)
> Locator set for R2: R1,...,Rj (or a subset)
> 
> The problem is that the tuple (flow label, src, dst) does not provide 
> enough information for proper demux
> 
> The possible solution for this is not to allow overlapping locator sets 
> when the same flow label value is being used in the two contexts.
> This means that in the previous case, when the context are established, 
> the nodes avoid adding locators to the locator sets that would result 
> in overlapping src,dst address pair combinations.
> 
> So, if we apply this to the previous example, the result is:
> 
> First communication: I1,R1
> 
> Second communication: I2,R2
> 
> At some point, I decides to create a SHIM context for the first 
> communication, so it proposes through SHIM signaling, the following 
> context parameter:
> 
> ULIDs: I1,R1
> Flow Label: f1
> Locator set for I1: I1,...,In
> 
> Upon reception of such information, the receiver R replies proposing 
> the following locator set for the context:
> 
> Locator set for R1: R1,R3...,Rj  (R2 is not included so that I2, R2 is 
> not valid combination for this context)
> 
> Next, the initiator establishes the SHIM context for the second 
> communication, proposing the following parameters:
> 
> ULIDs: I2,R2
> Flow Label: f1
> Locator set for I2: I1,...,In (or a subset)
> 
> At this point the receiver replies proposing the following locator set:
> 
> Locator set for R2: only R2 because all the remaining combinations are 
> included in the SHIM context of the first communication.
> 
> Through these means, proper demux can be guaranteed.
> 
> I think this provides proper demux functions.
> The problems that i see with this approach are:
> - Complexity
> - In some corner cases, some communications will end up with limited 
> fault tolerance because of a reduced set of locators.

I believe that this analysis is correct.  But if a host always generates a
complete (in terms of available prefixes) set of locators for every 2^20
active connections, and never reuses flow label values across these sets 
(i.e., keeps <IID(S), Fl> always unique) , then the complexity is tractable
and fault tolerance is not impacted, because the number of usable locators in
a shim6 context is not reduced.

Regards,

// Steve

Delivery-date: Sat, 30 Apr 2005 11:27:09 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Sat, 30 Apr 2005 13:26:26 +0200
To: Francis Dupont <[email-masked]>

[pruned CC list before my mail client runs out of memory...]

On 29-apr-2005 Francis Dupont wrote:

>    Why not adding a new extension header?

> => basically as there is no way to deal with a new extension header  
> without
> modifying code or more, this will kill all the boxes which are looking
> inside packets for good or less good reasons.

I don't think that in this stadium of IPv6 deployment this is that  
huge a deal.

Also, looks like RFC 2460 dropped the ball here. It actually draws  
extension headers as having a next header and a length field in a  
fixed place, but then doesn't say that all extension headers should  
look like that.

>    I think that at the moment I agree with you that flow labels  
> should be
>    used if the existing definitions of flow labels can be accomodated
>    (few though they are).

> => the problem with the overloading of flow labels is this should  
> likely
> break all other possible usages of flow labels (not a surprise).

Have you been reading other posts to this list the past week? I think  
they make it pretty clear that using the flow label for demux can be  
done without impact to other flow label use, at the cost of some  
extra complexity when selecting the flow label for a new session.

Delivery-date: Sat, 30 Apr 2005 09:09:56 +0000
From: marcelo bagnulo braun <[email-masked]>
Subject: Detailed approaches for demux
Date: Sat, 30 Apr 2005 11:09:17 +0200
To: shim6 <[email-masked]>

Hi,

This is an attempt to wrap up part of the exchange we have about=20
context tags. I have tried to write down how the detailed procedure for=20=

using the flow label would look like (based on Pekka S. initial mail).

It is a long mail, sorry for that, but i hope it helps to understand=20
the complexity of  the solutions and the trade offs involved.

Flow Label Approach

Goal: use the Flow Label of the IPv6 header to demultiplex incoming=20
SHIM data packets. Demux operation consists in translating the address=20=

(locators) contained in the source and destination address fields upon=20=

reception to the addresses used when the communication was established=20=

(ULIDs). In few words, demux is translating locators to ULIDs in=20
incoming packets. Note that demux is only required after a rehoming=20
event, after which the locators differ from the =10ULIDs. Before the=20
rehoming, the demux operation is null.

Requirements:
R1: Given a source and a destination address, the flow label value must=20=

remain constant during the lifetime of the communication. In other=20
words, when the initiator host establishes the communication, it=20
includes a flow label value. such value must remain unchanged during=20
the lifetime of the communication. However, note that: First, for each=20=

direction of the communication the flow label may be different, i.e.=20
packets flowing in different direction of a communication can carry=20
different flow label values. Second, after a rehoming event, it is=20
acceptable that the flow label value changes. This is because a=20
rehoming event implies a change in the addresses carried in packets, so=20=

the requirement to preserve the same flow label does not hold. This=20
seems reasonable since a rehoming event implies a change in the path,=20
so it seems reasonable to expect changes in the way packets are treated=20=

along the path.

R2: SHIM context delayed establishment must be supported. This means=20
that is must be possible to setup a regular (non SHIM) IPv6=20
communication between two SHIM enabled hosts and later on, establish a=20=

SHIM context for that communication, so that it can benefit from the=20
SHIM features. This implies that it is not possible to assume that SHIM=20=

signaling packets are exchanged during the establishment of the=20
communication.

R3: Dynamic locator set must be supported. This means that the locator=20=

set available for a SHIM context can change during the lifetime of the=20=

communication, and in particular during the lifetime of the SHIM=20
context. This means that it is not possible to assume that the locator=20=

set available for a context can be known beforehand.

Corollaries:

R1 & R2 imply that the flow label value used for packet carrying the=20
addresses used for establishing the communication (ULIDs) are assigned=20=

by the transmitter of the packets i.e. that if the communication is=20
established using IPA and IPB, then the flow label of packet flowing=20
from IPA to IPB is defined by IPA before sending the first packet (and=20=

the same in the other direction)

Flow label based mechanism

(This is basically what was described by Pekka S. in his first mail)

Initiator I with addresses S1,...,Sn
Receiver R with addresses R1,...,Rj

Initiator I sends the first packet of the communication and associates=20=

the flow label value fi. The flow label value selected is reserved and=20=

not used for any other communication. (This means that as long as the=20
communication exists or the SHHIM context exists, this value is not=20
used for any other communication, if it is possible, see below).

When establishing the SHIM context, use the same flow label value.

When re-homing, also use the same flow label value with alternative=20
locators.

Demux at the receiver side is performed based on (flow label, src, dst)

The problem is what happens when a host run out of available flow label=20=

values and need to start repeating. Note well that this happens when=20
the host has 1.048.576 (2^20) simultaneous communications.

If a repeated value is used in a communication with a different node,=20
then no problem, since the addresses will never collide.

So, the first measure to avoid problems is to avoid re-using flow label=20=

values for communications with the same host whenever is possible.
However, this is not always possible because the initiator may not be=20
aware that two communications are established with the same node.

So, the problem occurs when the same value is used for the same host.
This may occur because the initiator may not be aware that two=20
different addresses belong to the same receiver.
For example, consider the following case:
I establishes a communication with R1 using S1 as source address and=20
assigns the flow label value f1.
Next, I runs out of flow label values, and need to start repeating=20
values.
At this point, I establishes a communication with R2 using S2.
Since the Destination address R2 has not been previously used, I has no=20=

means to know that is the same host, so I assigns the flow label value=20=

f1.
When the SHIM contexts are established for each of the communications,=20=

the resulting contexts are:

SHIM context for the first communication:
ULIDs: I1,R1
Flow Label: f1
Locator set for I1: I1,...,In (or a subset)
Locator set for R1: R1,...,Rj (or a subset)

SHIM context for the second communication:
ULIDs: I2,R2
Flow Label: f1
Locator set for I2: I1,...,In (or a subset)
Locator set for R2: R1,...,Rj (or a subset)

The problem is that the tuple (flow label, src, dst) does not provide=20
enough information for proper demux

The possible solution for this is not to allow overlapping locator sets=20=

when the same flow label value is being used in the two contexts.
This means that in the previous case, when the context are established,=20=

the nodes avoid adding locators to the locator sets that would result=20
in overlapping src,dst address pair combinations.

So, if we apply this to the previous example, the result is:

First communication: I1,R1

Second communication: I2,R2

At some point, I decides to create a SHIM context for the first=20
communication, so it proposes through SHIM signaling, the following=20
context parameter:

ULIDs: I1,R1
Flow Label: f1
Locator set for I1: I1,...,In

Upon reception of such information, the receiver R replies proposing=20
the following locator set for the context:

Locator set for R1: R1,R3...,Rj  (R2 is not included so that I2, R2 is=20=

not valid combination for this context)

Next, the initiator establishes the SHIM context for the second=20
communication, proposing the following parameters:

ULIDs: I2,R2
Flow Label: f1
Locator set for I2: I1,...,In (or a subset)

At this point the receiver replies proposing the following locator set:

Locator set for R2: only R2 because all the remaining combinations are=20=

included in the SHIM context of the first communication.

Through these means, proper demux can be guaranteed.

I think this provides proper demux functions.
The problems that i see with this approach are:
- Complexity
- In some corner cases, some communications will end up with limited=20
fault tolerance because of a reduced set of locators.

Extension Header/DST option Approach

We could compare this with a solution based on carrying the context tag=20=

in an extension header/dst option.

The solution could be something like this:

The initiator establishes a communication. No SHIM context tag is=20
assigned.

When the context is established, a receiver-based context tag=20
allocation procedure is used, so that each side informs the peer a=20
unique context tag that has to be used for sending packets that carry=20
locators that differ from the ULIDs. Context tag can be of 128 bits, so=20=

to make sure that we never run out of them. (maybe a lower value would=20=

provide similar guarantees)

I think this would work too. Clearly, this is simpler. Clearly, it=20
introduces more overhead.

However, the differences are more relative in the current case. I mean,=20=

in the general case, we won't run out of flow label values, so it=20
normally will be like using an unique context tag. OTOH, normally,=20
there won't be outages, so, no extension header will be included in=20
packets.

Regards, marcelo=

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Apr 2005 14:39:36 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Fri, 29 Apr 2005 16:38:28 +0200

 In your previous mail you wrote:

   I think that at the moment I agree with you that flow labels should be
   used if the existing definitions of flow labels can be accomodated
   (few though they are).
   
=> the problem with the overloading of flow labels is this should likely
break all other possible usages of flow labels (not a surprise).
For instance if flow labels are changed to be allocated after the first
packet and/or by the receiver.

   The original assumption was that flow labels (in general, rather than in
   shim) would be sender selected.  Marcelo has mentioned that there may
   therefore be pre-shim flow labels in existence at negotiation time.
   
=> the flow label is selected by the sender before it sends the first
packet. IMHO shim stuff should not touch the flow label, i.e., the only
real but marginal question is whether the flow label should be reset when
an address in the IPv6 header is changed (there are pros and cons, and in
fact it doesn't really matter :-).

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Apr 2005 14:25:15 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Fri, 29 Apr 2005 16:00:03 +0200

 In your previous mail you wrote:

   > I am in favor of a destination option
   
   Could you comment on the issues that Erik and I sent w.r.t using the 
   destiantion option?
   
=> it seems the main issue is the overhead so I've addressed it in my message.

   >  (don't add a new extension header,
   > PLEASE!)
   
   Why not adding a new extension header?
   
=> basically as there is no way to deal with a new extension header without
modifying code or more, this will kill all the boxes which are looking
inside packets for good or less good reasons.
   
Regards

[email-masked]

Delivery-date: Fri, 29 Apr 2005 14:19:48 +0000
Date: Sat, 30 Apr 2005 00:17:57 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Francis Dupont <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, Pekka Savola <[email-masked]>, Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Francis,

Francis Dupont wrote:
> I am in favor of a destination option (don't add a new extension header,
> PLEASE!) because it seems a tag which can be used (and only the tag itself)
> for demultiplexing can be needed. IPsec has something very similar named
> an SPI and the simple constraint for SPIs to be usable for demultiplexing
> bt the receiver is they have to be assigned by the receiver.
> This is clearly impossible for a standard flow label so the shim tag should
> be assigned (the whole tag or a part of the tag) by the receiver in the
> initial shim negociation phase. IMHO the IKE SPI procedure should be
> copied as it...
> The extra cost of a destination option should not be a problem if the option
> is needed only in special cases (i.e., not in every packets).

I think that at the moment I agree with you that flow labels should be
used if the existing definitions of flow labels can be accomodated
(few though they are).

The original assumption was that flow labels (in general, rather than in
shim) would be sender selected.  Marcelo has mentioned that there may
therefore be pre-shim flow labels in existence at negotiation time.

I think it will be possible to accomodate these pre-existing labels
for the path between the original source and destination while still
allowing receiver selected flow labels for all other paths (and maybe
replace the original label on the home path after flow state timeout).

Of course, there are no major problems if the labels don't preexist the
shim negotiation.

Best Regards,
Greg

Delivery-date: Fri, 29 Apr 2005 13:39:48 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Fri, 29 Apr 2005 14:56:06 +0200
To: Francis Dupont <[email-masked]>

Hi Francis,

El 29/04/2005, a las 14:47, Francis Dupont escribi=F3:

> I am in favor of a destination option

Could you comment on the issues that Erik and I sent w.r.t using the=20
destiantion option?

(I am not sure where the archives are, but i can resend you the email=20
if you want)

>  (don't add a new extension header,
> PLEASE!)

Why not adding a new extension header?

Regards, marcelo

>  because it seems a tag which can be used (and only the tag itself)
> for demultiplexing can be needed. IPsec has something very similar=20
> named
> an SPI and the simple constraint for SPIs to be usable for=20
> demultiplexing
> bt the receiver is they have to be assigned by the receiver.
> This is clearly impossible for a standard flow label so the shim tag=20=

> should
> be assigned (the whole tag or a part of the tag) by the receiver in =
the
> initial shim negociation phase. IMHO the IKE SPI procedure should be
> copied as it...
> The extra cost of a destination option should not be a problem if the=20=

> option
> is needed only in special cases (i.e., not in every packets).
>
> Regards
>
> [email-masked]
>
> PS: even this is hard to implement, usually flow labels are from a
> pseudo-random generator and uniqueness is not checked.
>

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Apr 2005 13:29:45 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Extension header vs destiantion option 
Date: Fri, 29 Apr 2005 15:28:23 +0200

 In your previous mail you wrote:

   We have discussed this issue in the design team, and as far as i 
   remember. people that were involved in the design on MIPv6 argued for 
   using a new extension header rather than using a destination option. 

=> the problem was possible piggy-backing of the mobility header and
the compatibility with the current version of IPsec. The adopted solution
is to use a terminal header with a format compatible with an extension
header (to be able to change the decision) and to update IPsec architecture
with support of extension headers as selectors.

   The reasons for that, AFAIU, are the problems that appeared when using 
   the destination option. These were basically due to the fact that 
   Destination options are no ordered within the Destination Option 
   extension header.

=> no, this has nothing to do with MIPv6/IPsec issue.

   In addition there is the issue brought by Iljitsch, about the 
   destination option header being processed after the IPSec related 
   header. This seems to be in opposition with the architecture of the 
   shim, where the shim resides below the IPsec.

=> IMHO you are making a common confusion with the way IPsec is applied:
outgoing IPsec processing has two phases: in the first phase one decides
what processing is needed according to selectors (so this phase must
be done before shim application) and in the second phase processing is
applied on the packet, usually on the whole packet because of AH.
So the choice of where to put the IPsec extension header is more free
than you can believe...

   I guess that Erik or Jari could expand on this topic, but AFAIU, we 
   should consider a new Extension header rather than a Destiantion 
   option.
   
=> I don't like at all new extension header because this in fact supposes
to change all the boxes which look at inside packets: QoS classifiers,
firewalls, etc, just because there is no way to recognize and skip
a new extension header (note this includes end systems but they should
receive only packets they are supposed to know how to handle :-).

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Apr 2005 12:49:16 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked], Pekka Savola <[email-masked]>, Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself 
Date: Fri, 29 Apr 2005 14:47:48 +0200

I am in favor of a destination option (don't add a new extension header,
PLEASE!) because it seems a tag which can be used (and only the tag itself)
for demultiplexing can be needed. IPsec has something very similar named
an SPI and the simple constraint for SPIs to be usable for demultiplexing
bt the receiver is they have to be assigned by the receiver.
This is clearly impossible for a standard flow label so the shim tag should
be assigned (the whole tag or a part of the tag) by the receiver in the
initial shim negociation phase. IMHO the IKE SPI procedure should be
copied as it...
The extra cost of a destination option should not be a problem if the option
is needed only in special cases (i.e., not in every packets).

Regards

[email-masked]

PS: even this is hard to implement, usually flow labels are from a
pseudo-random generator and uniqueness is not checked.

Envelope-to: [email-masked]
Delivery-date: Fri, 29 Apr 2005 12:39:50 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Brian E Carpenter <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label - the problem 
Date: Fri, 29 Apr 2005 14:39:12 +0200

 In your previous mail you wrote:

   And I don't think a destination option is going to work as on  
   reception, the shim must be applied before all other headers are  
   processed. Think IPsec and fragmentation.
   
=> I don't understand your argument. Do you suggest fragmentation is
done before multihoming, i.e., there can be address changes intra packets?

Regards

[email-masked]

PS: mobility uses a destination option placed before fragmentation and/or
IPsec headers in order to be firewall friendly, not for any other reason.

Delivery-date: Thu, 28 Apr 2005 18:47:30 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Firewall "uniformity" issue
Date: Thu, 28 Apr 2005 20:47:06 +0200
To: Erik Nordmark <[email-masked]>

On 28-apr-2005, at 20:33, Erik Nordmark wrote:

> If we assume we always have deferred shim context establishment,  
> then the timeliness of the shim setup isn't critical, hence it  
> makes sense to avoid penalizing the data traffic (with firewall- 
> related loss, or differently protected by a SG). With this  
> assumption I think it makes sense to not try to put the two in the  
> same packet.

I agree that in most cases we wouldn't want to do this, but I also  
think being able to have the shim setup in transport/data carying  
packets will come in handy in the future. One very important aspect  
of having the shim setup in the initial packet is that the initial  
packet is the only one an attacker with sniffing capability can't  
guess about.

Delivery-date: Thu, 28 Apr 2005 18:34:05 +0000
Date: Thu, 28 Apr 2005 11:33:38 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Firewall "uniformity" issue

Iljitsch van Beijnum wrote:

> This is in line with my message from two days ago.
> 
> Another firewalling issue is whether we put the initial shim header  in 
> a packet that also has payload, or if we give it its own packet.  In the 
> former case if a firewall drops the packet we've also lost  data which 
> is never good. On the other hand having the shim in a data  packet is 
> more efficient.

In many cases we want to separate the shim setup from the data traffic, 
so that we can avoid doing anything in the shim for short-lived 
communication.
Thus e.g., a TCP SYN exchange will happen independently of the shim 
exchange.

With such separation, when the shim on the host says "I've sent more 
than N packets to this destination, let's try to setup shim state now", 
what are the tradeoffs in terms of combining the shim setup packet and 
some data packet into one?

Of course, the data packet might already be MTU size, so it makes sense 
to not try when the shim setup packet doesn't fit.
IPsec policies on the host shouldn't matter, because IPsec gets applied 
above the shim.

But there could be IPsec SGs along the path, which want to use 
protocol/port number selectors and protected some traffic, which would 
not "see" the data packet when it is hidden inside/after a shim header.
And then there is the firewall issue you bring up.

If we assume we always have deferred shim context establishment, then 
the timeliness of the shim setup isn't critical, hence it makes sense to 
avoid penalizing the data traffic (with firewall-related loss, or 
differently protected by a SG). With this assumption I think it makes 
sense to not try to put the two in the same packet.

    Erik

Delivery-date: Thu, 28 Apr 2005 18:05:59 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Firewall "uniformity" issue
Date: Thu, 28 Apr 2005 20:05:45 +0200
To: Erik Nordmark <[email-masked]>

On 28-apr-2005, at 19:36, Erik Nordmark wrote:

> Of course, once there are shim6 aware firewalls, we don't know how  
> they will behave. But we could at least recommend that they take  
> this issue into consideration, by recommending
> 1) that they not block shim6 by default, but instead look at the  
> carried (TCP, UDP, etc) payload
> 2) if they need to block shim6, block the context establishment and  
> testing parts of the protocol and not just the data packets

> Comments?

This is in line with my message from two days ago.

Another firewalling issue is whether we put the initial shim header  
in a packet that also has payload, or if we give it its own packet.  
In the former case if a firewall drops the packet we've also lost  
data which is never good. On the other hand having the shim in a data  
packet is more efficient.

Iljitsch

Delivery-date: Thu, 28 Apr 2005 17:36:34 +0000
Date: Thu, 28 Apr 2005 10:36:27 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: Firewall "uniformity" issue

Shim6 will introduce:
1. A control protocol used to
	- detect whether or not the peer supports shim6
	- establish state in the shims; the context setup protocol
	- test which locator pairs work

2. A way to carry a context tag with data packets, so that the receiver 
can determine whether and with which ULIDs replace the locators in the 
received packet.

Existing IPv6 firewalls are of course not aware of shim6, but we can 
assume that they do not out of hand reject packets based on the flow 
label field. But they might filter based on UDP ports, extension 
headers, destination options header, or the options contained in the 
destinations options header.

Thus we can potentially end up with a case where 1 or 2, but not the 
other, make it through the firewall (of course, we also have the case 
when both or neither make it through, but those don't require extra care 
  :-) )

The case when #1 makes it through, but #2 is blocked by the firewall is 
a bit undesirable, because the context setup protocol will think that it 
can fail over to using a different locator pair, and it can test that 
the alternative locator pair(s) are working, but when it starts sending 
data packets using an alternate, those data packets will be dropped by 
the firewall.

Thus it seems desirable, if the data packets using alternate locators 
are going to be dropped by the firewall, try to construct the control 
protocol so those packets would be dropped by the firewall as well. That 
way shim6 would know there is no use in trying alternate locators.

For the case when #2 is handled by overloading the flow label field, 
this proposal doesn't add any restrictions on #1, because we assume 
existing firewalls will not drop packets based on the value of the flow 
label field (even if the IP address fields change).

In in the case when #2 is a new extension header, or a new destination 
option, this leads to suggesting that #1 be carried using the same 
mechanism as #2.
For instance, if the data packets (after a failure has caused switching 
to a different locator pair), are embellished with a new extension 
header (IP protocol value XX), then it makes sense to do the context 
establishment and testing using IP protocol value XX as well.
Likewise, if the data packets are embellished with the new Destination 
option (value YY), then it makes sense to do #1 using packets that carry 
that Destination option as well.

Of course, once there are shim6 aware firewalls, we don't know how they 
will behave. But we could at least recommend that they take this issue 
into consideration, by recommending
1) that they not block shim6 by default, but instead look at the carried 
(TCP, UDP, etc) payload
2) if they need to block shim6, block the context establishment and 
testing parts of the protocol and not just the data packets

Comments?
     Erik

Delivery-date: Thu, 28 Apr 2005 17:15:32 +0000
Date: Thu, 28 Apr 2005 10:15:03 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Extension header vs destiantion option

marcelo bagnulo braun wrote:
> Hi,
> 
> I guess we also need to understand the differences between using a new 
> SHIM extension header to carry the context tag or use a new Destination 
> option for carrying it.
> 
> We have discussed this issue in the design team, and as far as i 
> remember. people that were involved in the design on MIPv6 argued for 
> using a new extension header rather than using a destination option. The 
> reasons for that, AFAIU, are the problems that appeared when using the 
> destination option. These were basically due to the fact that 
> Destination options are no ordered within the Destination Option 
> extension header. This result that it is not clear how to build the 
> destination option header, and that since the context tag determines if 
> the addresses are rewritten, then the resulting behavior may be affected 
> depending on the order in which destination options are placed.
> In addition there is the issue brought by Iljitsch, about the 
> destination option header being processed after the IPSec related 
> header. This seems to be in opposition with the architecture of the 
> shim, where the shim resides below the IPsec.
> However, if a new extension header is used, then the order is perfectly 
> defined and could be placed properly w.r.t. IPSec.
> 
> I guess that Erik or Jari could expand on this topic, but AFAIU, we 
> should consider a new Extension header rather than a Destiantion option.

At a high enough level of abstraction an extension header and a 
destination option are isomorphic; they both provide a bit bucket into 
which we can stuff a context tag. But there are several details that 
might be important.

A destination option would be the ideal answer if we want to be able to 
send it to nodes that might not implement shim6, because the option code 
  has bits to describe what such a receiver should do (ignore option, 
drop pkt, drop pkt and send ICMP error, etc).
Also, if there is a reasonable probability that multiple small 
destination options be used at the same time, then the fact that they 
can be more densely packed into a single destination options header 
might matter.

However, if there is no need for multiple options at the same time, the 
destination options approach has higher overhead than a separate 
extension header. A destination options header has a nxthdr and length 
field, plus the option needing a type and length. Thus a minimum size 
destination options header of 8 bytes can only carry 4 bytes of data.
A new extension header only have the nxthdr and length field, thus can 
carry two more bytes of useful data.

The more complex issues have to do with all what we went through in the 
Mobile IPv6 discussion (and in the interest of full disclosure, I think 
that using the destination options header for the MIPv6 Home address 
option was a mistake, but more about that later).

The issues that appeared (as I recall) were due to (not a complete list 
I suspect):
1. extension header ordering and whether or not there can be one, two, 
or more destination options headers
2. semantics of the destination options header and IPsec (recall that 
MIPv6 rides above IPsec, and the plan for shim6 is to sit below IPsec)
3. implementation issues around sharing the same destination options 
header when there are multiple sources of the options (some being set by 
the application, others being added by the MIPv6 code in the stack)

There's already been some emails on #1 on the shim6 list.

The hard issues in #2 came from the fact that the MIPv6 Home Address 
Option is defined to perform an address transformation (semantically it 
swaps the home address with the care of address in the IPv6 destination 
field). Given that IPsec policies typically care about IP addresses and 
IPsec SADBs use IP addresses as keys for lookup, this makes things a bit 
hairy. (But the MIP6 WG managed to figure things out in the end.)

I don't know to what extent #3 has been solved. It might be a very real 
issue if shim6 will use a destination option, *and* that option needs to 
go in the same destination options header as the home address option.
(But if the result would be that shim6 would have an additional, 
separate destination options header, this issue can be avoided.)

The fact that MIPv6 has taken the destination options header to perform 
*its* address transformation, and we need shim6 to carry bits which 
affect *its* address transformation, means that we need very 
well-defined ordering between the two if we want a chance of them 
co-existing for the same packet.
It is probably harder to do that if they share the same destination 
options header.
Furthermore, since the shim sits below IPsec and MIPv6 sits above IPsec, 
then, at least when IPsec will be used, we will end up with two separate 
destination options header. Thus any byte savings packing the options 
together in the same header will not appear.

As far as I know, we do not need the destination options capability to 
control what a receiver, which doesn't implement shim6, will do with the 
packet, because before applying shim6 to the data packets there will be 
a context setup exchange between the endpoints, which will detect when 
the peer doesn't implement shim6.

In summary, to me it seems like, if we are not going to use the flow 
label as a context tag, we might as well do a separate extension header. 
The destination option approach seems to have a lot more complexity than 
the new extension header and close to zero benefits.

     Erik

Delivery-date: Wed, 27 Apr 2005 09:28:33 +0000
Cc: Pekka Savola <[email-masked]>, Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Wed, 27 Apr 2005 11:27:53 +0200
To: [email-masked]

Hi Greg,

El 27/04/2005, a las 3:47, Greg Daley escribi=F3:
> I guess that there need to be some considerations on where the headers
> are (TCP, UDP, DestOpt), and their relative position with regards
> to IPSec (notably non-null encryption ESP).
>
> Clearly there should be some security mechanism with which to secure
> the mapping.

I am not sure what are considering here...

I mean, SHIM data packets will be different to those of MIPv6, becuase=20=

they will not carry multiple addresses for the DST(or src).
I mean in MIPv6, data packets carry both the HoA and the CoA (i.e. the=20=

ULID and the locator)
In shim, data packet will only carry the locator (which sometimes will=20=

also be the ULID, i.e. when no rehoming has occurred)

So in data packets, there is no need to protect no binding since there=20=

won't be any (contained in the data packets)

OTOH, SHIM signaling packets will carry the alternative locators for=20
the ULID (those are like BU i guess) Those packets do carry binding=20
information and need to be protected, but they will be protected=20
through a special SHIM security mechanisms (whether CGA or HBA). I=20
guess that both the locator and the security information will be=20
carried in a new extension header defined for shim imho.

>   It would be good to have sufficient information to
> identify which IPSec SA to use (some are identified by address) - this
> is the first Dest Option position from RFC2460, and then also to
> protect the binding for the identities and locators (either another
> destination option (inside ESP from RFC2460), or a payload).
>

You mean that SHIM is processed before IPSec, right?
In that case, the ULID is restored before IPSec processing...

I guess this is the goal, so that IPSec SA can survive outages, i.e.=20
that even if locator changes, packets are presented to IPSec as coming=20=

from the ULID

> This issue has been visited a few times in SEND (where IPsec wasn't=20
> used
> because of multicast, but included because of CGA discussion) and
> Mobile IPv6 (Where IPSec is used, but the external header is
> unprotected, and needs additional checks).
>

Right, imho this is the same for SHIM here, The shim header will not=20
protected by IPSec, but by a specific SHIM security mechanisms (keep in=20=

mind that data packets do not carry any SHIM binding information as=20
opoosed to MIP)

> Where the outside identifier for the signalling isn't globally unique
> (and what is...) there's going to be a difficulty in mapping the
> identifier if the new message comes from a location not in the set.
>

Well, i was thinking about this point, and i guess that the packet that=20=

contains a new locator that is not contained in the locator set known=20
by the peer will need to also carry the SHIM header contianing the=20
security information to validate that the new locator is securely=20
associated to the ULID. In this case, if the SHIM header processing is=20=

done before the packet processing (i don't know if this makes any=20
sense, though), the the result would be:

- A packet containing an unknown locator as source address and also=20
contains a SHIM header binding the unknown locator to an ULID for which=20=

a SHIM context exists.
So,
- The SHIM header is processed and the new locator contained in the is=20=

verified and added to the locator set available to the ULID
- Next, the IPv6 header is processed, but now the source locator is=20
contained in the set, so the packet can be demux properly
- The packet is processed by the SHIM and the ULID is restored.

> Personally, I guess that it's OK to have two identifiers, one of which
> could inhabit a destination option (if it was considered important).
>

imho this is not needed

what is needed is a context tag in order to demux packets that contain=20=

a locator that differs from the ULID used for the communication. (note=20=

that when the packet carries the ULIDs, there not even the need for a=20
context tag, it is just a regular IPV6 packet without extension header)

This context tag can be carried in an extension header or flow label.

Regards, marcelo

Delivery-date: Wed, 27 Apr 2005 01:48:49 +0000
Date: Wed, 27 Apr 2005 11:47:00 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
To: Pekka Savola <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Pekka,

Pekka Savola wrote:
> On Tue, 26 Apr 2005, Greg Daley wrote:
> 
>> Greg,
>> Who thinks flow-labels are better than extension headers, otherwise
>> shim6 looks too much like Mobile IPv6.
> 
> 
> Agreed.
> 
> However, it may be worth thinking a bit about the shim6 packet exchange 
> protocol itself.  Would that be based on UDP/TCP or destination options?
> 
> Because if it would make sense to model the shim6 exchange protocol with 
> destination options, it would seem relatively easy to support both; 
> carrying context tag could be done very easily if someone wants to do 
> that, but the implementations would still have to support flow label.
> 
> Then flow label could be used as a useful optimization, but one could 
> always fall back to using destination options as with the rest of the 
> shim6 protocol exchange if one wanted to.
>
I guess that there need to be some considerations on where the headers
are (TCP, UDP, DestOpt), and their relative position with regards
to IPSec (notably non-null encryption ESP).

Clearly there should be some security mechanism with which to secure
the mapping.  It would be good to have sufficient information to
identify which IPSec SA to use (some are identified by address) - this
is the first Dest Option position from RFC2460, and then also to
protect the binding for the identities and locators (either another
destination option (inside ESP from RFC2460), or a payload).

This issue has been visited a few times in SEND (where IPsec wasn't used
because of multicast, but included because of CGA discussion) and
Mobile IPv6 (Where IPSec is used, but the external header is
unprotected, and needs additional checks).

Where the outside identifier for the signalling isn't globally unique
(and what is...) there's going to be a difficulty in mapping the
identifier if the new message comes from a location not in the set.

Personally, I guess that it's OK to have two identifiers, one of which
could inhabit a destination option (if it was considered important).

If there's no mandatory requirement for destination options otherwise,
I guess that the processing would be up to the recipient (perhaps
mandatory to support on the receiver).

There are some minor potential problems if the destination option is
processed before locator update exchange, though, since an attacker not 
on the path which knows the identifier could inject packets and not
violate ingress filtering.

Greg

Delivery-date: Tue, 26 Apr 2005 23:41:16 +0000
Date: Tue, 26 Apr 2005 16:40:20 -0700
From: Erik Nordmark <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

Pekka Savola wrote:
> On Mon, 25 Apr 2005, Erik Nordmark wrote:
> 
>> This isn't the only option. With receiver-based tag allocation, then 
>> the receiver can choose which locators it advertises for which 
>> contexts. For instance, a receiver can have multiple locators in each 
>> prefix and keep them separate. So {P1:X, P2:Y} can use tag=1 and be 
>> associated with one context, and {P1:Z, P2:W} can use tag=1 and be 
>> associated with a different context. Of course, if the host doesn't do 
>> this, then it can assign the tags to that it never needs to look at 
>> the locators in order to lookup the context.
> 
> 
> I'm a bit confused -- we're still talking about flow label and extension 
> header/destination option both, right?

I was (apparently not clearly) restricting my comments about 
receiver-based allocation to the case when we don't overload the flow 
label as a context tag, but instead carry a tag explicitly somewhere 
else in the packet (e.g., in a new extension header or destination option)

> How would one perform receiver-based tag allocation with flow labels, 
> because the flow label is allocated when the sender sends out a first 
> packet and cannot be changed since?

One wouldn't.
Unless we are told that it is ok to have the transmitting shim start 
using a different flow label once the shim state has been set up with 
the peer.  But my assumption is that this would cause too much pain for 
other usage of the flow label.

    Erik

Delivery-date: Tue, 26 Apr 2005 12:22:01 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Extension header vs destiantion option
Date: Tue, 26 Apr 2005 14:21:24 +0200
To: Pekka Savola <[email-masked]>

On 26-apr-2005, at 13:10, Pekka Savola wrote:

> Destination options can be placed before routing, fragment or AH/ 
> ESP headers (see RFC2460 section 4.1), so this is not an issue.

But with the following caveat:

            note 1: for options to be processed by the first destination
                    that appears in the IPv6 Destination Address field
                    plus subsequent destinations listed in the Routing
                    header.

> The issue about different destination options inside the  
> destionation options header may be worth considering, though.  I  
> think there may be other issues stemming over from MIPv6 security  
> design as well. (Like, does the shim6 stuff need to be used as  
> IPsec selectors, which might be challenging for dest options.)

I think the main reason to make it a destination option rather than a  
header of its own is that a single destination option header can hold  
more than one destination option so you save some space if the  
options are small. However, there is also a penalty because of the  
additional layering, so the savings will only be in the order of a  
couple of bytes IF there is another destination option.

I'm starting to think along what you said in a previous message,  
where an option could be used when it's necessary, but it's left out  
when it can be optimized away. Since potentially, this is in almost  
all cases (i.e., the only time this can't be done is when using  
different ULIDs with overlapping locator sets towards the same host  
with an overlapping flow label and a higher-layer protocol that  
doesn't support port numbers or an SA.), there shouldn't be any long- 
term adverse effects of having an option but ONLY if the receiver can  
force the sender to omit the option when the receiver doesn't need  
it. This would allow for simple implementations at first and more  
advanced ones (after some real-world experience) later.

The identifier in such an option would ideally be a set of indexes  
pointing to:

- the shim6 state (= the association between the two hosts)
- the source ULID
- the destination ULID

Something like this could easily be encoded in 16+4+4 to 32+8+8 bits.

The destination host would tell the source host which shim6 state  
index to use (this value would remain constant as long as the  
association persists) and an ordered list of locators would be  
exchanged so they can be referenced by an index from there on.

Then there would have to be an "applicability statement" from the  
destination to the source, which can include a set of options like:

- never use the option (= locators for different ULIDs don't overlap)
- don't use the option for TCP and UDP (= I'll demux on port numbers)
- don't use the option for IPsec (= I'll demux on SA)
- don't use the option when flow label is known to be unique enough  
(= I'll demux on flow label)

If none of these is selected all packets where the shim has replaced  
addresses will have the option. Support for the first three would be  
mandatory, so including the option anyway would lead to an error. The  
last depends on how smart the source is about assigning flow labels  
so setting the option when the flow labels are in fact unique  
wouldn't lead to an error.

I think it makes sense to have the shim negotiation, demux and  
reachability test all rolled up into a shim extension header. Having  
all these as destination options would use up a lot of destination  
option number space and make identifying the shim harder, along with  
potential issues with ordering and coexistance with other destination  
options.

The advantage of having a header rather than use UDP (TCP isn't  
suitable) is that the header can either exist as its own packet or  
live between the IP header and payload. In IPv4, UDP would have a big  
advantage that it can traverse NAT and firewalls, but to the chagrin  
of some we're assuming no NAT in IPv6 and bang-for-your-buck ratio of  
working around firewalls would quickly deteriorate to below zero in  
the long term, and is arguably the wrong thing to do anyway.

Ok, going off the deep end now:

With a demux option present and having site-wide agreement on at  
least part of the list of source address prefixes, it would be easy  
to add a field that indicates that routers can safely rewrite source  
addresses.

Even deeper: if we apply some header compression on the subsequent  
headers we may even be able to compress the TCP/UDP/RTP header away  
for most packets    , so rather than making the packet 8 bytes  
longer, we're making it 12 bytes shorter (for TCP)! Now we're getting  
somewhere.  :-)

Delivery-date: Tue, 26 Apr 2005 11:10:45 +0000
Date: Tue, 26 Apr 2005 14:10:17 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Extension header vs destiantion option

On Tue, 26 Apr 2005, marcelo bagnulo braun wrote:
> In addition there is the issue brought by Iljitsch, about the destination 
> option header being processed after the IPSec related header. This seems to 
> be in opposition with the architecture of the shim, where the shim resides 
> below the IPsec.
> However, if a new extension header is used, then the order is perfectly 
> defined and could be placed properly w.r.t. IPSec.

Destination options can be placed before routing, fragment or AH/ESP 
headers (see RFC2460 section 4.1), so this is not an issue.

The issue about different destination options inside the destionation 
options header may be worth considering, though.  I think there may be 
other issues stemming over from MIPv6 security design as well. (Like, 
does the shim6 stuff need to be used as IPsec selectors, which might 
be challenging for dest options.)

-- 
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: Tue, 26 Apr 2005 08:37:40 +0000
Cc: shim6 <[email-masked]>, Greg Daley <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself
Date: Tue, 26 Apr 2005 10:37:35 +0200
To: Pekka Savola <[email-masked]>

Hi Pekka,

El 26/04/2005, a las 7:24, Pekka Savola escribi=F3:

> On Tue, 26 Apr 2005, Greg Daley wrote:
>> Greg,
>> Who thinks flow-labels are better than extension headers, otherwise
>> shim6 looks too much like Mobile IPv6.
>
> Agreed.
>
> However, it may be worth thinking a bit about the shim6 packet=20
> exchange protocol itself.  Would that be based on UDP/TCP or=20
> destination options?
>
> Because if it would make sense to model the shim6 exchange protocol=20
> with destination options, it would seem relatively easy to support=20
> both; carrying context tag could be done very easily if someone wants=20=

> to do that, but the implementations would still have to support flow=20=

> label.
>
> Then flow label could be used as a useful optimization, but one could=20=

> always fall back to using destination options as with the rest of the=20=

> shim6 protocol exchange if one wanted to.
>

I don't know...
This is the option that convinces me less... It has the added=20
complexity of dealing with both approaches. I would argue to pick just=20=

one of them and deal with it. I mean, SHIM looks already pretty complex=20=

to me without having multiple mechanisms to perform the same task.

Regards, marcelo

> --=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: Tue, 26 Apr 2005 08:35:12 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Extension header vs destiantion option
Date: Tue, 26 Apr 2005 10:34:36 +0200

Hi,

I guess we also need to understand the differences between using a new 
SHIM extension header to carry the context tag or use a new Destination 
option for carrying it.

We have discussed this issue in the design team, and as far as i 
remember. people that were involved in the design on MIPv6 argued for 
using a new extension header rather than using a destination option. 
The reasons for that, AFAIU, are the problems that appeared when using 
the destination option. These were basically due to the fact that 
Destination options are no ordered within the Destination Option 
extension header. This result that it is not clear how to build the 
destination option header, and that since the context tag determines if 
the addresses are rewritten, then the resulting behavior may be 
affected depending on the order in which destination options are 
placed.
In addition there is the issue brought by Iljitsch, about the 
destination option header being processed after the IPSec related 
header. This seems to be in opposition with the architecture of the 
shim, where the shim resides below the IPsec.
However, if a new extension header is used, then the order is perfectly 
defined and could be placed properly w.r.t. IPSec.

I guess that Erik or Jari could expand on this topic, but AFAIU, we 
should consider a new Extension header rather than a Destiantion 
option.

Comments?

regards, marcelo

Delivery-date: Tue, 26 Apr 2005 05:24:57 +0000
Date: Tue, 26 Apr 2005 08:24:47 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Greg Daley <[email-masked]>
cc: Erik Nordmark <[email-masked]>, marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header - protocol itself

On Tue, 26 Apr 2005, Greg Daley wrote:
> Greg,
> Who thinks flow-labels are better than extension headers, otherwise
> shim6 looks too much like Mobile IPv6.

Agreed.

However, it may be worth thinking a bit about the shim6 packet 
exchange protocol itself.  Would that be based on UDP/TCP or 
destination options?

Because if it would make sense to model the shim6 exchange protocol 
with destination options, it would seem relatively easy to support 
both; carrying context tag could be done very easily if someone wants 
to do that, but the implementations would still have to support flow 
label.

Then flow label could be used as a useful optimization, but one could 
always fall back to using destination options as with the rest of the 
shim6 protocol exchange if one wanted to.

-- 
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: Tue, 26 Apr 2005 05:20:33 +0000
Date: Tue, 26 Apr 2005 08:20:06 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Erik Nordmark <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

On Mon, 25 Apr 2005, Erik Nordmark wrote:
> This isn't the only option. With receiver-based tag allocation, then 
> the receiver can choose which locators it advertises for which 
> contexts. For instance, a receiver can have multiple locators in 
> each prefix and keep them separate. So {P1:X, P2:Y} can use tag=1 
> and be associated with one context, and {P1:Z, P2:W} can use tag=1 
> and be associated with a different context. Of course, if the host 
> doesn't do this, then it can assign the tags to that it never needs 
> to look at the locators in order to lookup the context.

I'm a bit confused -- we're still talking about flow label and 
extension header/destination option both, right?

How would one perform receiver-based tag allocation with flow labels, 
because the flow label is allocated when the sender sends out a first 
packet and cannot be changed since?

Or are you assuming that with receiver based allocation, the receivers 
would keep some kind of internal shim6 mapping table which would map 
{source addresses, destination addresses, flow label} values to a 
shim6-specific context tag (which might or might not be provided to 
the apps as auxialiry data) ?

This would work as long as, (AFAICS)
  - the receiver knows which locators the peer has before receiving the 
first packet from a new locator (i.e., the earlier discussion with me 
and Marcelo that the sender can't just switch over to using a new 
source locator, it must be negotiated with the shim protocol first)

  - we don't care about the {src,dst,flow} clashes, the implementations 
do mitigating techniques to avoid them (they happen very rarely in any 
case), or there is a mechanism like you wrote which allows the 
receiver to reject adding a locator (or inform that shim6 won't 
work with that particular locator at least for the moment)

And the general assumption of shim6 is,
  - the implementations' port number space is unique across all the IP 
addresses, so that there can't be two apps sitting at a port at two 
different IP addresses.  Otherwise the shim would end up having to 
rewrite ports as well and that wouldn't be good.

-- 
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: Tue, 26 Apr 2005 02:52:12 +0000
Date: Tue, 26 Apr 2005 12:51:16 +1000
From: Greg Daley <[email-masked]>
Subject: Re: Flow label versus Extension header
To: Erik Nordmark <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Reply-to: [email-masked]
Organization: Monash University

Hi Erik,

Thanks for encouraging the receiver-based allocation idea.

I was reading the thread trying to get up to date, and reading
all the descriptions of trying to fix sender-side systems hurt to
look at.

Erik Nordmark wrote:
> marcelo bagnulo braun wrote:
> 
>> I mean, do you think that if context tag values are repeated across 
>> different context, based on the fact that locator set of the peer are 
>> disjoint, receiver based context tag allocation can guarantee proper 
>> demux?
>>
>> I mean, as i see it, when we are handling dynamic locator sets, the 
>> only option to guarantee proper demuxing is to solely rely in the 
>> context tag i.e. not include the addresses in the demux operation. 
> 
> 
> This isn't the only option. With receiver-based tag allocation, then the 
> receiver can choose which locators it advertises for which contexts.
> For instance, a receiver can have multiple locators in each prefix and 
> keep them separate. So {P1:X, P2:Y} can use tag=1 and be associated with 
> one context, and {P1:Z, P2:W} can use tag=1 and be associated with a 
> different context.
> Of course, if the host doesn't do this, then it can assign the tags to 
> that it never needs to look at the locators in order to lookup the context.

I guess this provides a potential extension to the set of identifiers,
but only if the locators are likely to remain separate.

If there was going to be a problem with collision between sets, there
may be possibility for migration from one (reused) identifier to a
receiver unique identifier at locator proposal time, if needed.

It may be possible to have a different identifier (an extended session
identifier) only used during the signaling phase which disambiguates
session maps if there's a collision.

This may allow usage of the flow label on the forwarding plane, without
having unidentifiable proposals to add locators to a non-unique
identifier.

I'd guess the simple case (and fairly general) would be to have the
receiver allocate unique labels in most cases.

[chop]
>> and finally because of the expected number of sessions, probably we 
>> need a bigger field than the flow label in order to guarantee 
>> uniqueness of the context tag.
>>
>> I would say that this is the simpler approach. I may not be the most 
>> efficient though.
> 
> 
> I agree it is simpler.
> 
> One could augment it with the receiver ability, when the peer wants to 
> add locators to the set, to be able to refuse the addition (due to a 
> potential conflict).
> 
> If that mechanism is present then the receiver can ensure that a tuple 
> <src locator, dst locator, tag> always uniquely identifies one shim 
> context. It is't clear to me what tag allocation algorithm the host 
> would use to maximize the utility of such a scheme. When the allocation 
> is done, the host has been told the (initial) set of locators for the 
> peer, so it could at least verify that there isn't overlap between 
> those. So we can handle overlap in the initial sets that the peers send 
> in the context establishment, and we can handle dynamic locators, but 
> the host would have to refuse when a the overlap is due to the dynamic 
> addition locators by the peer.
> 
> I don't know if this provides good enough benefits.

There's a good argument to allow sequential allocation, and recover
old allocations with soft-state (timeout of agreed lifetime, no activity
on an ID for a long period).

Certain peerings could be allocated longer lifetimes (for example, based
on IPSec SA lifetime).  By default hosts having difficulty allocating
unique identifiers (for example reaching an allocation threshold) would
start re-using identifiers.

For these hosts, adds/moves/changes of locators to sets may become more
challenging, as refusals and renegotiation occur.

If a recipient can negotiate movement of a session to a different
(unique) identifier, then this can mitigate the issue for troublesome
sessions.

Greg,
Who thinks flow-labels are better than extension headers, otherwise
shim6 looks too much like Mobile IPv6.

Delivery-date: Mon, 25 Apr 2005 17:08:32 +0000
Date: Mon, 25 Apr 2005 10:08:14 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

marcelo bagnulo braun wrote:

> I mean, do you think that if context tag values are repeated across 
> different context, based on the fact that locator set of the peer are 
> disjoint, receiver based context tag allocation can guarantee proper demux?
> 
> I mean, as i see it, when we are handling dynamic locator sets, the only 
> option to guarantee proper demuxing is to solely rely in the context tag 
> i.e. not include the addresses in the demux operation. 

This isn't the only option. With receiver-based tag allocation, then the 
receiver can choose which locators it advertises for which contexts.
For instance, a receiver can have multiple locators in each prefix and 
keep them separate. So {P1:X, P2:Y} can use tag=1 and be associated with 
one context, and {P1:Z, P2:W} can use tag=1 and be associated with a 
different context.
Of course, if the host doesn't do this, then it can assign the tags to 
that it never needs to look at the locators in order to lookup the context.

> Because if we 
> inlcude the addresses in the demux, and we have repeated context tags, 
> it always may occur that we end up with two contexts that have the same 
> context tag (because we are using repeated context tags) and with the 
> same locators (because they were added after we assigned the context 
> tag, allowing to assign the same context tags initially, because 
> initially the context tags were disjoints)
> 
> So, as i see it, the easier mechanisms to guarantee proper demux is to 
> assign unique context tags and demux only based in context tags (not 
> consider the addresses). Moreover, in order to guarantee this 
> uniqueness, the simplest way is probably to use different context tags 
> for each direction and to perform receiver based context tag allocation.
> and finally because of the expected number of sessions, probably we need 
> a bigger field than the flow label in order to guarantee uniqueness of 
> the context tag.
> 
> I would say that this is the simpler approach. I may not be the most 
> efficient though.

I agree it is simpler.

One could augment it with the receiver ability, when the peer wants to 
add locators to the set, to be able to refuse the addition (due to a 
potential conflict).

If that mechanism is present then the receiver can ensure that a tuple 
<src locator, dst locator, tag> always uniquely identifies one shim 
context. It is't clear to me what tag allocation algorithm the host 
would use to maximize the utility of such a scheme. When the allocation 
is done, the host has been told the (initial) set of locators for the 
peer, so it could at least verify that there isn't overlap between 
those. So we can handle overlap in the initial sets that the peers send 
in the context establishment, and we can handle dynamic locators, but 
the host would have to refuse when a the overlap is due to the dynamic 
addition locators by the peer.

I don't know if this provides good enough benefits.

   Erik

Delivery-date: Mon, 25 Apr 2005 15:17:37 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Mon, 25 Apr 2005 17:17:02 +0200
To: Brian E Carpenter <[email-masked]>

On 25-apr-2005, at 15:23, Brian E Carpenter wrote:

> It all goes to convince me that a destination option is the
> cleaner answer by far.

And:

> I think it is more a matter of not overloading those bits, which we  
> are
> sure to end up doing by using the flow label.

Well, flow label and an extra header are just two of the options. We  
can also forbid having more than one ULID set between two hosts or  
making the locator sets for different ULIDs disjoint.

Extra bytes cost real money in the real world every time a packet  
flows over the network, while the cleanliness of the solution or its  
implementation complexity are mostly one-time problems.

And I don't think a destination option is going to work as on  
reception, the shim must be applied before all other headers are  
processed. Think IPsec and fragmentation.

Delivery-date: Mon, 25 Apr 2005 14:19:37 +0000
Date: Mon, 25 Apr 2005 15:22:23 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Erik Nordmark <[email-masked]>
CC: Pekka Savola <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, [email-masked]
Subject: Re: flow label demultiplexing

Erik Nordmark wrote:
> Pekka Savola wrote:
> 
>> First off, let me try to describe the main idea:
>>
>> Host A has locators 2001::1 and 2001::2.  When it establishes 
>> communications to B, it uses 2001::1 as source and 2002::B1 as 
>> destination locator (and 2002::B2 is backup).  That communication uses 
>> flow label = "1".
>>
>> Now, Host A (and presumably, also B depending on how it allocates flow 
>> labels) marks flow label = 1 as reserved for 
>> ({2001::1,2001::2},{2002::B1,2002::B2}).  Normally, the flow label 
>> implementation either doesn't do reservation at all or would just mark 
>> (2001::1,2002::B1,1) as reserved.
> 
> 
> This part of the description doesn't make sense. Host A doesn't yet know 
> that 2002::B2 is part of the peer locator set.
> Thus it has the choice to reserve the flow label for
>  - ({2001::1,2001::2},{2002::B1}), which could cause problems as you
>    point out
>  - ({2001::1,2001::2}, *)
> 
>> Now, multihoming context is exchanged.
> 
> 
> At this point in time, the host finds out 2002::B2, thus it could
> potentially refine the flow label to only be reserved for
> ({2001::1,2001::2},{2002::B1,2002::B2}). But if CGA is used we allow B 
> to add it its locator set, so it isn't obvious to me that this 
> refinement is safe; at a minimum A would have to be able to refuse B's 
> attempt to add locators to the set that would cause a conflict for A.
> 
>> After that, the host tries to establish a new flow from 2001::1 to 
>> 2002::B2; unless there is reservation, it could end up picking "1" as 
>> well, which could create issues when either 2002::B1 or 2002::B2 fails 
>> because the flow labels overlap.
>>
>> Of course, there is still a race condition between the communication 
>> is established and the multihoming context is set up -- there's no way 
>> to do the reservation for destination locators before you know which 
>> ones they are.
>>
>> The problem I was referring to above is that caused either by that 
>> race condition.
> 
> 
> I don't view this as a race condition that should be minimized or 
> avoided, but as a result of the conscious design decision to allow 
> deferred context establishment. We don't want to require all 
> communication to establish state in the shim, but instead allow the peer 
> to use heuristics (e.g., #packets sent/recvd) to decide whether and when 
> some particular communication has the right cost/benefit tradeoff before
> establishing the state in the shim.
> 
> A result of this is that there might be rather long lived, but few 
> packets exchanged, communications that do not have the state hence do 
> not know the peer locator set, which would need to have 
> ({2001::1,2001::2}, *) reservations for the flow label.

It all goes to convince me that a destination option is the
cleaner answer by far.

    Brian

Delivery-date: Mon, 25 Apr 2005 14:19:06 +0000
Date: Mon, 25 Apr 2005 15:23:52 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: Erik Nordmark <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label - the problem

Iljitsch van Beijnum wrote:
> On 24-apr-2005, at 19:52, Erik Nordmark wrote:
> 
>>> Yes, but not necessarily at this point. Presumably, the shim  
>>> address  remapping will happen early in the processing of a  packet, 
>>> while  scanning the full list of extension headers happens  much later.
> 
> 
>> Can you explain why such (undesired from a performance perspective)  
>> type of behavior would be required?
> 
> 
> Well, I can't be sure, but if processing of any other headers that  may 
> be present requires knowledge of the ULIDs then it could be  necessary 
> to go through the list of headers twice.
> 
> But...
> 
>> AFAIK it is sufficient for the implementation to step through the  
>> extension headers, and when and if it finds a shim6 extension  header, 
>> it would lookup the shim6 context state, and remap the IP  address 
>> fields to the ULIDs that are contained in that context.
> 
> 
> I guess that that should be enough if we can proscribe that the  headers 
> that come before the shim header (counting from the beginning  of the 
> packet, not the order in which they are created) only deal  with the 
> locators and the ones that come later only deal with the ULID.
> 
> So in that case there aren't any adverse effects when the header  isn't 
> present.
> 
> I still don't like it, though.  :-)
> 
> (And the argument that a header will give us a more bits is a  fallacy, 
> 20 bits is already more than we should want to use up. Less  is more, as 
> a long label only increases lookup times.)

I think it is more a matter of not overloading those bits, which we are
sure to end up doing by using the flow label.

    Brian

Delivery-date: Sun, 24 Apr 2005 20:18:41 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Sun, 24 Apr 2005 22:18:16 +0200
To: Erik Nordmark <[email-masked]>

On 24-apr-2005, at 19:52, Erik Nordmark wrote:

>> Yes, but not necessarily at this point. Presumably, the shim  
>> address  remapping will happen early in the processing of a  
>> packet, while  scanning the full list of extension headers happens  
>> much later.

> Can you explain why such (undesired from a performance perspective)  
> type of behavior would be required?

Well, I can't be sure, but if processing of any other headers that  
may be present requires knowledge of the ULIDs then it could be  
necessary to go through the list of headers twice.

But...

> AFAIK it is sufficient for the implementation to step through the  
> extension headers, and when and if it finds a shim6 extension  
> header, it would lookup the shim6 context state, and remap the IP  
> address fields to the ULIDs that are contained in that context.

I guess that that should be enough if we can proscribe that the  
headers that come before the shim header (counting from the beginning  
of the packet, not the order in which they are created) only deal  
with the locators and the ones that come later only deal with the ULID.

So in that case there aren't any adverse effects when the header  
isn't present.

I still don't like it, though.  :-)

(And the argument that a header will give us a more bits is a  
fallacy, 20 bits is already more than we should want to use up. Less  
is more, as a long label only increases lookup times.)

Delivery-date: Sun, 24 Apr 2005 19:50:25 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header
Date: Sun, 24 Apr 2005 21:49:40 +0200
To: Erik Nordmark <[email-masked]>

El 24/04/2005, a las 19:52, Erik Nordmark escribi=F3:
>
>> Second,  are you assuming that at this point the receiver know all=20
>> the locator set of the initiator? are you assuming the the locator=20
>> sets are static? Becuase if the locator sets are dynamic then i think=20=

>> that no one can be sure that the locator sets won't overlap in the=20
>> future...
>
> You're probably assuming that the same tag is used in both directions.
>

i think i am not (but i am not sure :-)

I mean, do you think that if context tag values are repeated across=20
different context, based on the fact that locator set of the peer are=20
disjoint, receiver based context tag allocation can guarantee proper=20
demux?

I mean, as i see it, when we are handling dynamic locator sets, the=20
only option to guarantee proper demuxing is to solely rely in the=20
context tag i.e. not include the addresses in the demux operation.=20
Because if we inlcude the addresses in the demux, and we have repeated=20=

context tags, it always may occur that we end up with two contexts that=20=

have the same context tag (because we are using repeated context tags)=20=

and with the same locators (because they were added after we assigned=20
the context tag, allowing to assign the same context tags initially,=20
because initially the context tags were disjoints)

So, as i see it, the easier mechanisms to guarantee proper demux is to=20=

assign unique context tags and demux only based in context tags (not=20
consider the addresses). Moreover, in order to guarantee this=20
uniqueness, the simplest way is probably to use different context tags=20=

for each direction and to perform receiver based context tag=20
allocation.
and finally because of the expected number of sessions, probably we=20
need a bigger field than the flow label in order to guarantee=20
uniqueness of the context tag.

I would say that this is the simpler approach. I may not be the most=20
efficient though.

Regards, marcelo

>    Erik
>

Delivery-date: Sun, 24 Apr 2005 17:57:31 +0000
Date: Sun, 24 Apr 2005 10:57:19 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label - the problem

Iljitsch van Beijnum wrote:

> No, this id would be looked at when selecting the flow label for a  new 
> session. I.e.: when selecting a new flow label, the host would  see if 
> the flow label overlaps with one currently used, and then:
> 
> - overlaps with known non-shim session: allow if dest addr is different
> - overlaps with known shim session: allow if shim id is different
> - overlaps with session of unknown type: don't allow
> 
> There are probably other places wher ethe shim id would be useful too.

I don't understand how and when the initiator would discover this id.

The flow label should presumably be allocated before the initiator sends 
the first packet, but at that point in time all the shim knows is one 
ULID=locator (perhaps the application knows more, such as a FQDN and 
multiple ULIDs that it got from the DNS, but I don't think we can should 
  assume this).

Unless we always require a context establishment before sending the 
first ULP packet, you'd have to pick some "unique enough" flow label 
without knowing this id.

So I don't see how the ID helps.

    Erik

Delivery-date: Sun, 24 Apr 2005 17:52:58 +0000
Date: Sun, 24 Apr 2005 10:52:52 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label - the problem

Iljitsch van Beijnum wrote:
> On 21-apr-2005, at 16:00, Brian E Carpenter wrote:
> 
>>> You still need to work your way through each packet to see if  there  
>>> is a header, so it's still bad even if the header isn't  there...
> 
> 
>> Er, every node has to step through all Next Headers anyway, whether or
>> not there is an extra header there.
> 
> 
> Yes, but not necessarily at this point. Presumably, the shim address  
> remapping will happen early in the processing of a packet, while  
> scanning the full list of extension headers happens much later.

Can you explain why such (undesired from a performance perspective) type 
of behavior would be required?

AFAIK it is sufficient for the implementation to step through the 
extension headers, and when and if it finds a shim6 extension header, it 
would lookup the shim6 context state, and remap the IP address fields to 
the ULIDs that are contained in that context.

Thus when there is no shim6 extension header (because the communication 
hasn't been rehomed to different locators yet, or the peer doesn't 
support shim6), there is no effect in the code path.

    Erik

Delivery-date: Sun, 24 Apr 2005 17:52:24 +0000
Date: Sun, 24 Apr 2005 10:52:15 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

marcelo bagnulo braun wrote:
>

>> The flow label value would be allocated by the sender before sending 
>> the first packet to the peer.
>>
> 
> i think i agree but i would like to confirm why is that so.
> 
> This would be so because once the communication is initiated, the flow 
> label value cannot be changed. And this is so because other usages 
> related to the flow label (i.e. not becuase the usage of the flow label 
> by the shim) Is this correct? I mean, if the only consider the usage of 
> the flow id in the shim context, the flow id label could be changed 
> during the context establsihement so we would be in a similar situation 
> than in the context tag, right?

Yes, I it's the potential other usage of the flow label that constrains 
us to not change the flow label once the communication has started.
I don't know if this constraint it make explicit in the flow label RFC 
though.

>> The receiver-based allocation has the benefit that the receiver can 
>> make sure that the tag (either by itself or in combination with the 
>> destination locator) will uniquely identify the context even if the 
>> receivers set of locators change in the future.
> 
> 
> 
> Not sure why is that...
> I mean, first of all, the receiver based allocation can allow the 
> receiver to make sure that the tag by itself will uniquely identify the 
> context _for the receiver_... i mean how the receiver can be sure that 
> the context tag was not already in use by the initator in another context?

The receiver would only care about the tag being unique for itself, thus 
B cares about the context tag that A uses to send to B. The context tag 
which B uses when sending to A could be a different number. (Which is 
why I used the "sender"/"receiver" terms and not "initiator"/"responder".)

> Second,  are you assuming that at this point the receiver know all the 
> locator set of the initiator? are you assuming the the locator sets are 
> static? Becuase if the locator sets are dynamic then i think that no one 
> can be sure that the locator sets won't overlap in the future...

You're probably assuming that the same tag is used in both directions.

    Erik

Delivery-date: Sun, 24 Apr 2005 17:32:12 +0000
Date: Sun, 24 Apr 2005 10:31:38 -0700
From: Erik Nordmark <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: shim design vs mobility/renumbering

Pekka Savola wrote:
> Hi,
> 
> This may be an obvious thing, but possibly worth bringing up explicitly..
> 
> When I read the specs, the obvious architectural approach taken by the 
> shim6 approach -- not defining a separate identified name space -- has 
> most implications in particular on renumbering and mobility.
> 
> In particular, especially with mobility, the locators are expected to 
> become obsolete in a relatively frequent basis.  As the ULID is tied to 
> the locators, this has a couple of implications:
> 
>  1) what to do when the locator used for ULID has been removed from
>     the node (permanently)?
> 
>  2) in particular, what to do in the circumstances are such that
>     the locators get assigned to other hosts?
> 
>  3) specifically, then what if the host wants to communicate with the
>     host which was given its previous locator, if the locator is
>     still used as ULID?
> 
> For a site multihoming solution it might be able to assume the apps 
> could continue using the old ULID as long as it works.

The WG certainly needs to decide to what to recommend on these points.
I guess it depends on the probability of the identical IP address being 
assigned to another host when the prefix is reassigned.

> However, for mobility ("frequent renumbering") I doubt this would be 
> sufficient.  But having to change the ULID would defeat the purpose of 
> IP mobility, so that's unacceptable.  The sessions can't be changed to 
> use a different ULID either (without changes to the transport 
> protocols), so that's a no-go.

For mobility, if we are assuming that peers need to be able to contact 
the mobile host using some fixed or slow changing IP address (something 
that can be placed in the DNS, or registered with SIP, etc), then you 
naturally end up with the need for the host having some locators which 
are more stable than others. The more stable locators would be like MIP 
Home Address, and the less stable ones like MIP Care of Addresses.
And you'd have something like a Home Agent responsible for tunneling 
packets addresses to a home locators to one of the care of locators.

Applying the shim to that type of mobility is conceptually simple; just 
restrict the ULIDs to being the home locators.

> So, from the mobility perspective, a solution like HIP is better. 

AFAIK HIPs approach to mobility is architecturally isomorphic to MIP in 
that a fixed point is used in order to handle the case when both 
endpoints move at the same time, as well as providing a reasonably 
stable locator for initial contact. There used to be a name for what is 
architecturally similar to the Home Agent, but draft-ietf-hip-mm-01 now 
just says:
    In these
    situations there is a need for some helper functionality in the
    network.  Such functionality is out of scope of this document

*If* HIP can provide a mechanism to dynamically lookup up HIs/HITs in 
the future, there would most likely still be a need for such helper 
functionality, because it isn't likely that a system which can scale to 
Internet scale for these lookups, can also handle hosts that move and 
need to change their registered locators every few seconds.

Thus I think need benefits and issues around a stable identifier name 
space which is not tied to the IP addresses are quite different than the 
issues around mobility at the IP layer. Stable identifiers would help 
with renumbering, assuming there would be a lookup system that can scale 
to Internet size, but tracking the hosts movement is a different kettle 
of fish.

    Erik

Delivery-date: Sun, 24 Apr 2005 14:06:53 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim design vs mobility/renumbering
Date: Sun, 24 Apr 2005 12:32:32 +0200
To: Pekka Savola <[email-masked]>

Hi Pekka,

El 23/04/2005, a las 22:18, Pekka Savola escribi=F3:

> Hi,
>
> This may be an obvious thing, but possibly worth bringing up=20
> explicitly..
>
> When I read the specs, the obvious architectural approach taken by the=20=

> shim6 approach -- not defining a separate identified name space -- has=20=

> most implications in particular on renumbering and mobility.
>
> In particular, especially with mobility, the locators are expected to=20=

> become obsolete in a relatively frequent basis.  As the ULID is tied=20=

> to the locators, this has a couple of implications:
>
>  1) what to do when the locator used for ULID has been removed from
>     the node (permanently)?
>

well, this may well be the case in site multihoming too, like when we=20
have a long lasting outage in a direct link to one of the providers. In=20=

such case, i guess it would make sense to deprecate the associated=20
prefix, right?
In the failure detection draft i think there is some discussion about=20
this... I think we have considered the possibility of defining a=20
signaling message to inform that one of the locators is out, so that=20
the peer doesn't use it to send packets. The address would still be=20
used as ULID in established communications, but i wouldn't be used as=20
ULID for new communications just as in regular IPv6 when an address is=20=

deprecated.

So, i think this can be supported.

Now if we move to the mobility case, then i guess that we may need some=20=

additional information to handle it properly, but for now i think it=20
may be feasible. I mean, in mobility we have HoAs and CoAs. HoA are=20
likely to become unreachable for long periods, but still we want to=20
keep on using them as ULIDs. I guess that this is slightly different=20
from the case above, since we would use the message to inform the peer=20=

that the HoA is unreachable, but we want to keep on using it as ULID=20
(as oposed to previous case, where unreachable addresses weren't used=20
as ULIDs anymore). I guess this is not a big problem, just internal=20
policy (within the host)
OTOH, the CoAs are likely to come and go quite frequently. In this=20
case, the CoA will be reachable but we probably don't want to use it as=20=

ULID, just use it as locator, and once it is no longer reachable simply=20=

inform the peer that it should not be used anymore. Again i don't see=20
this as particularly difficult... but maybe (and probably) i am missing=20=

some of the difficulties

>  2) in particular, what to do in the circumstances are such that
>     the locators get assigned to other hosts?
>

Well wouldn't this be similar to the MIPv6 case? I mean, this can=20
happen in MIPv6 also, right?

I guess that the point here is what is the probability of this event?=20
in ipv6 with 64 bit interface ids....

>  3) specifically, then what if the host wants to communicate with the
>     host which was given its previous locator, if the locator is
>     still used as ULID?

Again, what is the probablity of this event? (even less than the=20
previous one)

In addition, i would say that CoAs shouldn't be used as ULIDs in=20
general. Moreover, i am not sure that this would be a problem, since=20
one would simply be the ULID and the other a lcoator (i agree that=20
would be really weird though :-)

>
> For a site multihoming solution it might be able to assume the apps=20
> could continue using the old ULID as long as it works.
>
> However, for mobility ("frequent renumbering") I doubt this would be=20=

> sufficient.

I am sorry but i am not sure i see the problem yet...

>  But having to change the ULID would defeat the purpose of IP=20
> mobility, so that's unacceptable.  The sessions can't be changed to=20
> use a different ULID either (without changes to the transport=20
> protocols), so that's a no-go.
>

Agree

> So, from the mobility perspective, a solution like HIP is better.

Not sure about that... The HoA makes a very good ULID in anycase...

>  Shim6 could provide the same functionality, but only if the ULIDs=20
> would always use a unique, non-renumbering idenftifier (a ULA?).  But=20=

> if those weren't routable, then the shim6 context would have to be=20
> exchanged up front.
>

Yes, this is one of the possibilities that we are likely to explore i=20
guess. The problem is that soem stuff breaks, like refferals...

> So, this brings two main issues/observations:
>
>  a) is the assumption 1) good enough for site multihoming?  and if
>     not, what else would be needed?
>

I am sorry but i am not fully understanding what is the assumption and=20=

what are the implications of it.

>  b) while shim6 could maybe be extended to also be a mobility
>     protocol, mobility support seems to have very different
>     requirements (e.g., about the identifier name space, when to
>     exchange the identifiers) that ruling that out at this
>     point seems justified.
>

I wouldn't support that for now. I think more analysis is needed=20
(actually i think it could work)

Regards, marcelo

> --=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: Sun, 24 Apr 2005 14:06:51 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header
Date: Sun, 24 Apr 2005 12:08:09 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

El 24/04/2005, a las 5:19, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> Any additional considerations?
>
> I think there are some considerations related to when and by whom the=20=

> value is allocated.

good point

> The flow label value would be allocated by the sender before sending=20=

> the first packet to the peer.
>

i think i agree but i would like to confirm why is that so.

This would be so because once the communication is initiated, the flow=20=

label value cannot be changed. And this is so because other usages=20
related to the flow label (i.e. not becuase the usage of the flow label=20=

by the shim) Is this correct? I mean, if the only consider the usage of=20=

the flow id in the shim context, the flow id label could be changed=20
during the context establsihement so we would be in a similar situation=20=

than in the context tag, right?

> A context tag carried separately doesn't need to be allocated until=20
> the context is established. This allows the receiver of the packet=20
> (carrying the tag) to do the allocation (and pass it to the peer as=20
> part of the context establishment).
> The receiver-based allocation has the benefit that the receiver can=20
> make sure that the tag (either by itself or in combination with the=20
> destination locator) will uniquely identify the context even if the=20
> receivers set of locators change in the future.

Not sure why is that...
I mean, first of all, the receiver based allocation can allow the=20
receiver to make sure that the tag by itself will uniquely identify the=20=

context _for the receiver_... i mean how the receiver can be sure that=20=

the context tag was not already in use by the initator in another=20
context?

Second,  are you assuming that at this point the receiver know all the=20=

locator set of the initiator? are you assuming the the locator sets are=20=

static? Becuase if the locator sets are dynamic then i think that no=20
one can be sure that the locator sets won't overlap in the future...

Actually, for me, the benefit of a context tag carried separately is=20
that it will probably have more bits, and we won't ran out of them

> One additional thing we haven't discussed much yet is that there can=20=

> be a different flow label or context tag for each direction, and that=20=

> each end needs to be able to uniquely find the shim state based on=20
> both the flow label/tag and locators the *peer sent* (for normal=20
> reception), and the flow label and locators *it sent* itself (to be=20
> able to demux an ICMP error to the right context).
> I haven't figured out how this can be handled, nor whether the flow=20
> label (and sender-based allocation) or a context tag (with potential=20=

> for receiver or sender-based allocation) makes any difference.
>

Well, imho, the context tag is used to demux incoming packets. So, it=20
must uniquely identify packets to the receiver. I guess that the=20
context tag of outgoing packets can be set to any value by the=20
transmitter i.e. it doesn't affect the transmitter.

So, i guess that the best option from this p.o.v. (and also probably=20
the most complex one) is to perform receiver-based context tag=20
allocation independet for each direction of the communication. This=20
means that each side of the communication informs the other side which=20=

context tag must be used to send packets.
i.e. Host a informs host b the context tag that host b must use when=20
sending packets to host a
and Host b informs host a the context tag that host a must use when=20
sending packets to host b

There are then two context tags, one per direction and each one is sure=20=

that this context tag is not used for any other incoming communication.=20=

The problem occurs when we ran out of context tag values. This can be=20
the case if using flow id, while i don't think this is an issue for an=20=

alternative context tag.

Regards, marcelo

>    Erik
>

Delivery-date: Sun, 24 Apr 2005 08:48:51 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Sun, 24 Apr 2005 10:48:42 +0200
To: Erik Nordmark <[email-masked]>

On 24-apr-2005, at 5:28, Erik Nordmark wrote:

>> However, a good way to enforce this is to disallow overlap  
>> between  ULIDs and additional locators. So if a host sees prefixes  
>> A and B, it  forms four addresses:
>> A::ULID
>> A::locator-for-B
>> B::ULID
>> B::locator-for-A

> I wouldn't say that this is forbidding the applications from  
> selecting the ULID. Instead I view this as a different way to carry  
> information to the receiver to help it disambiguate the packets  
> (and what rewriting is needed before passing the packets to the  
> ULP); you are effectively carrying that information in the IP  
> address fields.

Right, and these are big and many bits in them can generally be  
filled in by the host so that could work very well.

>> Another way is to allow more than a single shim6 association at  
>> one  time between two hosts,

> I don't understand how this would work.
> Whether or not there is a single shim6 association isn't the key  
> issue.
> The issue is that the receiver will need to handle packets with the  
> same locator pair in them, where some of them need to have those  
> locators replaced with different ULIDs before passing them to the ULP.
> To do this there has to be something in the packet that can  
> distinguish the packets. Could be by effectively carrying the  
> disambiguating information in the address fields as you suggest  
> above, the flow label, or some separate context tag carried in the  
> packet. And this extra information can be skipped when the receiver  
> doesn't have to rewrite the address fields.

I was trying to address the issue on a conceptual level with the  
above and this:

>> or to have transport sessions with different  ULIDs within a  
>> single association. In this case there are four ways  to determine  
>> the right ULID set:

The difference is that either you send letters addressed to different  
people living at the same address in different envelopes, which has  
the upside that there doesn't have to be any demux info in the letter  
itself but the downside that there must be more demux info on the  
envelope and more envelopes, or you send all letters to one address  
in one envelope and demux the letters when they come out of the  
envelope.

For TCP/UDP/SCTP/RTP the port numbers can be used to demux, and the  
flow label can take the place of the port numbers as an optimization.

Delivery-date: Sun, 24 Apr 2005 08:41:23 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim design vs mobility/renumbering
Date: Sun, 24 Apr 2005 10:40:39 +0200
To: Pekka Savola <[email-masked]>

On 23-apr-2005, at 22:18, Pekka Savola wrote:

> In particular, especially with mobility, the locators are expected  
> to become obsolete in a relatively frequent basis.  As the ULID is  
> tied to the locators, this has a couple of implications:

>  1) what to do when the locator used for ULID has been removed from
>     the node (permanently)?

>  2) in particular, what to do in the circumstances are such that
>     the locators get assigned to other hosts?

>  3) specifically, then what if the host wants to communicate with the
>     host which was given its previous locator, if the locator is
>     still used as ULID?

In regular multihoming this wouldn't happen, but of course there will  
be people who think it's a good idea to try this...

(Even though you'd have to work long and hard to get host B to use  
the address that host A just released in IPv6.)

I think for now we have to say we can't support this. At some later  
date we'll want to revisit the non-locator (UL)ID thing anyway, and  
this could solve the above without too many problems.

Delivery-date: Sun, 24 Apr 2005 03:28:32 +0000
Date: Sat, 23 Apr 2005 20:28:17 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label - the problem

Iljitsch van Beijnum wrote:
> You guys are making all of this WAY too difficult.
> 
> The problem we have to deal with is the possibilities of two  
> transport-level sessions that share the same shim6 association using  
> different ULIDs.
> 
> One way to deal with this is to forbid it. So implementations would  
> have to choose source and destination ULIDs and stick with those for  
> any particular shim6 association. However, this is bad for load  
> balancing and it's possible that two sessions to different ULIDs turn  
> out to terminate on the same host unexpectedly, in which case a full  
> shim6 association wouldn't be able to form.

I don't think we can forbid this, since it is the applications/ULPs that 
select at least the destination ULID, and in some cases the source ULID 
as well.

> However, a good way to enforce this is to disallow overlap between  
> ULIDs and additional locators. So if a host sees prefixes A and B, it  
> forms four addresses:
> 
> A::ULID
> A::locator-for-B
> B::ULID
> B::locator-for-A

I wouldn't say that this is forbidding the applications from selecting 
the ULID. Instead I view this as a different way to carry information to 
the receiver to help it disambiguate the packets (and what rewriting is 
needed before passing the packets to the ULP); you are effectively 
carrying that information in the IP address fields.

> Another way is to allow more than a single shim6 association at one  
> time between two hosts, 

I don't understand how this would work.
Whether or not there is a single shim6 association isn't the key issue.
The issue is that the receiver will need to handle packets with the same 
locator pair in them, where some of them need to have those locators 
replaced with different ULIDs before passing them to the ULP.
To do this there has to be something in the packet that can distinguish 
the packets. Could be by effectively carrying the disambiguating 
information in the address fields as you suggest above, the flow label, 
or some separate context tag carried in the packet. And this extra 
information can be skipped when the receiver doesn't have to rewrite the 
address fields.

>or to have transport sessions with different  
> ULIDs within a single association. In this case there are four ways  to 
> determine the right ULID set:
> 
    Erik

Delivery-date: Sun, 24 Apr 2005 03:20:08 +0000
Date: Sat, 23 Apr 2005 20:19:20 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

marcelo bagnulo braun wrote:

> Any additional considerations?

I think there are some considerations related to when and by whom the 
value is allocated.
The flow label value would be allocated by the sender before sending the 
first packet to the peer.

A context tag carried separately doesn't need to be allocated until the 
context is established. This allows the receiver of the packet (carrying 
the tag) to do the allocation (and pass it to the peer as part of the 
context establishment).
The receiver-based allocation has the benefit that the receiver can make 
sure that the tag (either by itself or in combination with the 
destination locator) will uniquely identify the context even if the 
receivers set of locators change in the future.

One additional thing we haven't discussed much yet is that there can be 
a different flow label or context tag for each direction, and that each 
end needs to be able to uniquely find the shim state based on both the 
flow label/tag and locators the *peer sent* (for normal reception), and 
the flow label and locators *it sent* itself (to be able to demux an 
ICMP error to the right context).
I haven't figured out how this can be handled, nor whether the flow 
label (and sender-based allocation) or a context tag (with potential for 
receiver or sender-based allocation) makes any difference.

    Erik

Delivery-date: Sat, 23 Apr 2005 20:23:03 +0000
Date: Sat, 23 Apr 2005 13:22:54 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: flow label demultiplexing

Iljitsch van Beijnum wrote:

>> Well, there could packets with the same src and dst address, that 
>> belong to different communications with different ULIDs, right? the 
>> flow label is to determine the proper demux context.
> 
> 
> Under what circumstances would having different associations between the 
> same source and destination locator sets be necessary and/or useful?

Presumably we can't assume that the shim will control which ULIDs are 
selected; some upper layer like the application or transport protocol 
will in many cases select the destination ULID, and perhaps also the 
source ULID.

Hence the shim needs to be able to deal with the fact that between host 
A and host B, one or both of them having multiple ULIDs, there might be 
communication which uses different ULID combinations.

When the communication is established, we don't know the equivalence 
sets for the remote hosts.
For instance, host A might establish communication with www.foo.example 
and www.bar.example, each having different IP addresses in the DNS (B 
and C in this example), but the IP addresses might be handled by the 
same peer host.
In such a case there is no choice but to (initially) have different 
associations for the different ULID combinations. Once A realizes that 
the locator sets are common (or at least partially overlapping) for B 
and C, it could potentially merge those into the same context to save on 
the "test" traffic, but it would still need to retain the separate flow 
labels so that the receiver knows which packets need to have which ULIDs 
when they are delivered to the upper layer protocol.
So I don't think such merging makes the demultiplexing any easier.

    Erik

Delivery-date: Sat, 23 Apr 2005 20:18:35 +0000
Date: Sat, 23 Apr 2005 23:18:29 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: shim design vs mobility/renumbering

Hi,

This may be an obvious thing, but possibly worth bringing up 
explicitly..

When I read the specs, the obvious architectural approach taken by 
the shim6 approach -- not defining a separate identified name space -- 
has most implications in particular on renumbering and mobility.

In particular, especially with mobility, the locators are expected to 
become obsolete in a relatively frequent basis.  As the ULID is tied 
to the locators, this has a couple of implications:

  1) what to do when the locator used for ULID has been removed from
     the node (permanently)?

  2) in particular, what to do in the circumstances are such that
     the locators get assigned to other hosts?

  3) specifically, then what if the host wants to communicate with the
     host which was given its previous locator, if the locator is
     still used as ULID?

For a site multihoming solution it might be able to assume the apps 
could continue using the old ULID as long as it works.

However, for mobility ("frequent renumbering") I doubt this would be 
sufficient.  But having to change the ULID would defeat the purpose of 
IP mobility, so that's unacceptable.  The sessions can't be changed to 
use a different ULID either (without changes to the transport 
protocols), so that's a no-go.

So, from the mobility perspective, a solution like HIP is better. 
Shim6 could provide the same functionality, but only if the ULIDs 
would always use a unique, non-renumbering idenftifier (a ULA?).  But 
if those weren't routable, then the shim6 context would have to be 
exchanged up front.

So, this brings two main issues/observations:

  a) is the assumption 1) good enough for site multihoming?  and if
     not, what else would be needed?

  b) while shim6 could maybe be extended to also be a mobility
     protocol, mobility support seems to have very different
     requirements (e.g., about the identifier name space, when to
     exchange the identifiers) that ruling that out at this
     point seems justified.

-- 
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: Sat, 23 Apr 2005 20:14:41 +0000
Date: Sat, 23 Apr 2005 13:13:45 -0700
From: Erik Nordmark <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, [email-masked]
Subject: Re: flow label demultiplexing

Pekka Savola wrote:

> First off, let me try to describe the main idea:
> 
> Host A has locators 2001::1 and 2001::2.  When it establishes 
> communications to B, it uses 2001::1 as source and 2002::B1 as 
> destination locator (and 2002::B2 is backup).  That communication uses 
> flow label = "1".
> 
> Now, Host A (and presumably, also B depending on how it allocates flow 
> labels) marks flow label = 1 as reserved for 
> ({2001::1,2001::2},{2002::B1,2002::B2}).  Normally, the flow label 
> implementation either doesn't do reservation at all or would just mark 
> (2001::1,2002::B1,1) as reserved.

This part of the description doesn't make sense. Host A doesn't yet know 
that 2002::B2 is part of the peer locator set.
Thus it has the choice to reserve the flow label for
  - ({2001::1,2001::2},{2002::B1}), which could cause problems as you
    point out
  - ({2001::1,2001::2}, *)

> Now, multihoming context is exchanged.

At this point in time, the host finds out 2002::B2, thus it could
potentially refine the flow label to only be reserved for
({2001::1,2001::2},{2002::B1,2002::B2}). But if CGA is used we allow B 
to add it its locator set, so it isn't obvious to me that this 
refinement is safe; at a minimum A would have to be able to refuse B's 
attempt to add locators to the set that would cause a conflict for A.

> After that, the host tries to establish a new flow from 2001::1 to 
> 2002::B2; unless there is reservation, it could end up picking "1" as 
> well, which could create issues when either 2002::B1 or 2002::B2 fails 
> because the flow labels overlap.
> 
> Of course, there is still a race condition between the communication is 
> established and the multihoming context is set up -- there's no way to 
> do the reservation for destination locators before you know which ones 
> they are.
> 
> The problem I was referring to above is that caused either by that race 
> condition.

I don't view this as a race condition that should be minimized or 
avoided, but as a result of the conscious design decision to allow 
deferred context establishment. We don't want to require all 
communication to establish state in the shim, but instead allow the peer 
to use heuristics (e.g., #packets sent/recvd) to decide whether and when 
some particular communication has the right cost/benefit tradeoff before
establishing the state in the shim.

A result of this is that there might be rather long lived, but few 
packets exchanged, communications that do not have the state hence do 
not know the peer locator set, which would need to have 
({2001::1,2001::2}, *) reservations for the flow label.

    Erik

Delivery-date: Fri, 22 Apr 2005 08:24:02 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Fri, 22 Apr 2005 10:23:43 +0200
To: marcelo bagnulo braun <[email-masked]>

On 22-apr-2005, at 9:55, marcelo bagnulo braun wrote:

> From the practical perspective, i guess that using the flow id may  
> be a bit more trickier than an extension header, but it also has a  
> clear practical benefit w.r.t. overhead.

Exactly.

> My main doubt about using the flow id is w.r.t. alternatives usages  
> of the flow id that may end up clashing with this shim usage. I  
> mean, the flow id is located in the main IPv6 header, which makes  
> it useful as a field to be used in a hop per hop basis, i.e.  
> routers can used for forwarding and so on. OTOH, the shim protocol,  
> and in particular the context tag used for demux, is clearly an end  
> to end information i.e. it won't be used by routers, and there is  
> no need to place it in the main IPv6 header.

I understand. But I believe the current suggestions for using the  
flow label for shim6 don't get in the way of using the flow label for  
other purposes, and we in fact use it for what its intended purpose:  
to identify flows/sessions quickly without having to look deep inside  
the packet.

Delivery-date: Fri, 22 Apr 2005 07:56:00 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label - the problem
Date: Fri, 22 Apr 2005 09:55:32 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 21/04/2005, a las 22:03, Iljitsch van Beijnum escribi=F3:

> On 21-apr-2005, at 20:53, marcelo bagnulo braun wrote:
>
>>> In BGP and other routing protocols systems usually have a router id=20=

>>> so another system can detect that it's talking to the same remote=20
>>> system over different links. We can do the same thing here. This=20
>>> value doesn't have to have any meaning to the remote system, the=20
>>> only requirement is that it's unique. A good choice for this would=20=

>>> be one of the IP addresses of a host or maybe the interface=20
>>> identifier if that contains enough uniqueness.
>
>> but in this case, the real context tag used for demux would be the=20
>> id, not the flow id value. so you would have to include it in every=20=

>> packet, back to where we start, i am afraid.. or i am missing=20
>> something?
>
> No, this id would be looked at when selecting the flow label for a new=20=

> session. I.e.: when selecting a new flow label, the host would see if=20=

> the flow label overlaps with one currently used, and then:
>
> - overlaps with known non-shim session: allow if dest addr is =
different
> - overlaps with known shim session: allow if shim id is different
> - overlaps with session of unknown type: don't allow
>
> There are probably other places wher ethe shim id would be useful too.
>

ok, i agree this could work AFAICT.

 =46rom the practical perspective, i guess that using the flow id may be =
a=20
bit more trickier than an extension header, but it also has a clear=20
practical benefit w.r.t. overhead.

My main doubt about using the flow id is w.r.t. alternatives usages of=20=

the flow id that may end up clashing with this shim usage. I mean, the=20=

flow id is located in the main IPv6 header, which makes it useful as a=20=

field to be used in a hop per hop basis, i.e. routers can used for=20
forwarding and so on. OTOH, the shim protocol, and in particular the=20
context tag used for demux, is clearly an end to end information i.e.=20
it won't be used by routers, and there is no need to place it in the=20
main IPv6 header.

So, my concern is that bits in the main IPv6 header are a precious=20
scarce resource, and using them when it is not compelling (i.e. hop by=20=

hop processing of the field) seems to me a waste. Perhaps we should=20
leave those for who really need them and don't have the choice of using=20=

an extension header.

Regards, marcelo

> Iljitsch
>

Delivery-date: Thu, 21 Apr 2005 20:04:07 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 22:03:34 +0200
To: marcelo bagnulo braun <[email-masked]>

On 21-apr-2005, at 20:53, marcelo bagnulo braun wrote:

>> In BGP and other routing protocols systems usually have a router  
>> id so another system can detect that it's talking to the same  
>> remote system over different links. We can do the same thing here.  
>> This value doesn't have to have any meaning to the remote system,  
>> the only requirement is that it's unique. A good choice for this  
>> would be one of the IP addresses of a host or maybe the interface  
>> identifier if that contains enough uniqueness.

> but in this case, the real context tag used for demux would be the  
> id, not the flow id value. so you would have to include it in every  
> packet, back to where we start, i am afraid.. or i am missing  
> something?

No, this id would be looked at when selecting the flow label for a  
new session. I.e.: when selecting a new flow label, the host would  
see if the flow label overlaps with one currently used, and then:

- overlaps with known non-shim session: allow if dest addr is different
- overlaps with known shim session: allow if shim id is different
- overlaps with session of unknown type: don't allow

There are probably other places wher ethe shim id would be useful too.

Iljitsch

Delivery-date: Thu, 21 Apr 2005 18:53:41 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 20:53:35 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 21/04/2005, a las 19:50, Iljitsch van Beijnum escribi=F3:

> On 21-apr-2005, at 16:25, marcelo bagnulo braun wrote:
>
>> We have a host A with 4 addresses: IPa1, IPa2, IPa3 and IPa4 and host=20=

>> b with 2 addresses (to keep it simple) IPb1 and IPb2
>> Now a communication between these two hosts. The shim context between=20=

>> host a and host b has IPa1 and IPb1 as ulid and, because whatever=20
>> reason (policy, efficiency) host a decide only to include on=20
>> alternative locator in the context, say, IPa2 and host b does not=20
>> include any additional locators. At this point, the context 1 between=20=

>> host a and host b has: ulids: IPa1 and IPb1, locator set for a: IPa1=20=

>> and IPa2, locator set for b IPb1.
>
> I see the problem. Howerver, this should be easy to fix even if we=20
> don't want to mandate exchanging the full locator set (which doesn't=20=

> seem unreasonable to me). In BGP and other routing protocols systems=20=

> usually have a router id so another system can detect that it's=20
> talking to the same remote system over different links. We can do the=20=

> same thing here. This value doesn't have to have any meaning to the=20
> remote system, the only requirement is that it's unique. A good choice=20=

> for this would be one of the IP addresses of a host or maybe the=20
> interface identifier if that contains enough uniqueness.
>
>

but in this case, the real context tag used for demux would be the id,=20=

not the flow id value. so you would have to include it in every packet,=20=

back to where we start, i am afraid.. or i am missing something?

Regards, marcelo

Delivery-date: Thu, 21 Apr 2005 17:54:05 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 19:53:56 +0200
To: Brian E Carpenter <[email-masked]>

On 21-apr-2005, at 16:00, Brian E Carpenter wrote:

>> You still need to work your way through each packet to see if  
>> there  is a header, so it's still bad even if the header isn't  
>> there...

> Er, every node has to step through all Next Headers anyway, whether or
> not there is an extra header there.

Yes, but not necessarily at this point. Presumably, the shim address  
remapping will happen early in the processing of a packet, while  
scanning the full list of extension headers happens much later.

> If incoming traffic for virtual address X in a rack of servers is
> assigned dynamically when a new session starts, it may be assigned
> to different boxes for different sessions. Same thing for virtual
> address Y and virtual address Z. So you end up with {X,Y} and {X,Z}
> being locator 2-tuples for two different boxes, and then {X,Y,Z} is  
> not
> a valid locator 3-tuple. The fact that locator sets intersect does
> not mean that you can form their union.

I see no reason why we would have to support configurations like  
this. If people want to do this, it's their job to sort out the  
problems.

Delivery-date: Thu, 21 Apr 2005 17:52:02 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 19:50:46 +0200
To: marcelo bagnulo braun <[email-masked]>

On 21-apr-2005, at 16:25, marcelo bagnulo braun wrote:

> We have a host A with 4 addresses: IPa1, IPa2, IPa3 and IPa4 and  
> host b with 2 addresses (to keep it simple) IPb1 and IPb2
> Now a communication between these two hosts. The shim context  
> between host a and host b has IPa1 and IPb1 as ulid and, because  
> whatever reason (policy, efficiency) host a decide only to include  
> on alternative locator in the context, say, IPa2 and host b does  
> not include any additional locators. At this point, the context 1  
> between host a and host b has: ulids: IPa1 and IPb1, locator set  
> for a: IPa1 and IPa2, locator set for b IPb1.

I see the problem. Howerver, this should be easy to fix even if we  
don't want to mandate exchanging the full locator set (which doesn't  
seem unreasonable to me). In BGP and other routing protocols systems  
usually have a router id so another system can detect that it's  
talking to the same remote system over different links. We can do the  
same thing here. This value doesn't have to have any meaning to the  
remote system, the only requirement is that it's unique. A good  
choice for this would be one of the IP addresses of a host or maybe  
the interface identifier if that contains enough uniqueness.

Delivery-date: Thu, 21 Apr 2005 14:25:21 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 16:25:31 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 21/04/2005, a las 13:33, Iljitsch van Beijnum escribi=F3:

> On 21-apr-2005, at 13:11, marcelo bagnulo braun wrote:
>
>>> But it's not just the overhead. The problem is that adding bytes to=20=

>>> the packet increases the work that must be done per packet. This is=20=

>>> also very bad.
>
>> Ok, no arguing that extra overhead is bad, but keep in mind that the=20=

>> overhead is only cause when there is a rehoming event i.e. that the=20=

>> locator being carried is different from the ULID of the session.
>
> You still need to work your way through each packet to see if there is=20=

> a header, so it's still bad even if the header isn't there...
>

what Brian said...

>>> As I said before, the only thing needed to make the flow label=20
>>> usable for this, and without taking away from its other uses, is=20
>>> avoid reusing flow labels for sessions with an unknown shim6 status.
>
>> Not sure if a agree here.
>> I mean, are you cosnidering the case where new locators can be added=20=

>> after the context has been established?
>
> In general: yes. There may be some corner cases, though. Are you=20
> thinking about the situation where a locator that first belongs to one=20=

> host later belongs to another host?
>

No, this is not what i was thinking about (even if this situation seems=20=

also to describe a valid situation that Brian depicts), but i was=20
considering the situation where a locator initially belongs to one=20
session and then the same locator is added to a different session. see=20=

details below...

>> I mean, the requirement is to verify that those context that have=20
>> intersecting locator set use different flow id values.
>
> How can different associations have overlapping locator sets?
>

Ok. Consider this situation

We have a host A with 4 addresses: IPa1, IPa2, IPa3 and IPa4 and host b=20=

with 2 addresses (to keep it simple) IPb1 and IPb2
Now a communication between these two hosts. The shim context between=20
host a and host b has IPa1 and IPb1 as ulid and, because whatever=20
reason (policy, efficiency) host a decide only to include on=20
alternative locator in the context, say, IPa2 and host b does not=20
include any additional locators. At this point, the context 1 between=20
host a and host b has: ulids: IPa1 and IPb1, locator set for a: IPa1=20
and IPa2, locator set for b IPb1.

Next another communication is established between host a and host b.=20
Because the application is the one that chooses the ulids to used,=20
let's consider the case that the ulids used for this new context 2 are:=20=

IPa3 and IPb2. Again for policy reasons, host a decides to include only=20=

one additional locator in the context, IPa4 and host b does not include=20=

any additional one. At this point, context 2 has IPa3 and IPb2 as ulids=20=

and IPa3,IPa4 as locators for host A and IPb2 as locator for host b

This basically means that they could eventually use the same flow id,=20
because there is no overlapping between the locator set of the=20
different contexts.

Now what happen if host a decide to include IPa3  and host b decides to=20=

include IPb2 as an alternative locators in context 1? basically, the=20
locator set of context 1 will overlap with the locator set of context=20
2, and packets carrying addresses IPa3 and IPb2 cannot be demultiplexed=20=

right?

(note: i agree that this situation may not be very likely, but still i=20=

guess it is possible)

The harm here is that one of the locators will not be accepted i.e.=20
node b won't try to include IPb2 in context 2, i guess.

>> so if you are assuming that we have an static set of locators, then=20=

>> this is easy, since you can verify it when the session is=20
>> established.
>
>> However if you assume dynamic locator sets, then this is simply=20
>> impossible, since you cannot possible verify what will happen in the=20=

>> future i.e. if some of the locators included in one context won't be=20=

>> later on added to another context that has the same flow id value=20
>> associated.
>
> But the problem only exists when we have communication with the=20
> locator in question beforehand. So what would have to happen is that=20=

> there is shim6 communication between two hosts, but there is also=20
> communication from one host to a locator without shim6, and then that=20=

> locator is bound to the existing shim6 association. I agree that this=20=

> can happen, but only for a very limited time: either the=20
> shim6-agnostic session will start up shim6 negotiations, or the=20
> existing association will add the new locator.
>
> In other words: sessions move out of the state where their flow label=20=

> can't be reused for other sessions fairly quickly because either they=20=

> turn out shim-enabled and then we know the set of locators for which=20=

> the flow label must remain unique, or they turn out shim-incable and=20=

> the flow label can be reused for any other destination address.
>
>

see the example above, i don't think this is only related to the case=20
where there are non shim communications...

regards, marcelo

Delivery-date: Thu, 21 Apr 2005 14:01:10 +0000
Date: Thu, 21 Apr 2005 16:00:50 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label - the problem

Iljitsch van Beijnum wrote:
> On 21-apr-2005, at 13:11, marcelo bagnulo braun wrote:
> 
>>> But it's not just the overhead. The problem is that adding bytes  to 
>>> the packet increases the work that must be done per packet.  This is 
>>> also very bad.
> 
> 
>> Ok, no arguing that extra overhead is bad, but keep in mind that  the 
>> overhead is only cause when there is a rehoming event i.e. that  the 
>> locator being carried is different from the ULID of the session.
> 
> 
> You still need to work your way through each packet to see if there  is 
> a header, so it's still bad even if the header isn't there...

Er, every node has to step through all Next Headers anyway, whether or
not there is an extra header there.

> 
>>> As I said before, the only thing needed to make the flow label  
>>> usable for this, and without taking away from its other uses, is  
>>> avoid reusing flow labels for sessions with an unknown shim6 status.
> 
> 
>> Not sure if a agree here.
>> I mean, are you cosnidering the case where new locators can be  added 
>> after the context has been established?
> 
> 
> In general: yes. There may be some corner cases, though. Are you  
> thinking about the situation where a locator that first belongs to  one 
> host later belongs to another host?

Bingo. That's the point about virtualized IP addresses in a rack of
servers - addresses may well jump from box to box, or be created
and destroyed.

> 
>> I mean, the requirement is to verify that those context that have  
>> intersecting locator set use different flow id values.
> 
> 
> How can different associations have overlapping locator sets?

If incoming traffic for virtual address X in a rack of servers is
assigned dynamically when a new session starts, it may be assigned
to different boxes for different sessions. Same thing for virtual
address Y and virtual address Z. So you end up with {X,Y} and {X,Z}
being locator 2-tuples for two different boxes, and then {X,Y,Z} is not
a valid locator 3-tuple. The fact that locator sets intersect does
not mean that you can form their union.

    Brian

> 
>> so if you are assuming that we have an static set of locators, then  
>> this is easy, since you can verify it when the session is established.
> 
> 
>> However if you assume dynamic locator sets, then this is simply  
>> impossible, since you cannot possible verify what will happen in  the 
>> future i.e. if some of the locators included in one context  won't be 
>> later on added to another context that has the same flow  id value 
>> associated.
> 
> 
> But the problem only exists when we have communication with the  locator 
> in question beforehand. So what would have to happen is that  there is 
> shim6 communication between two hosts, but there is also  communication 
> from one host to a locator without shim6, and then that  locator is 
> bound to the existing shim6 association. I agree that this  can happen, 
> but only for a very limited time: either the shim6- agnostic session 
> will start up shim6 negotiations, or the existing  association will add 
> the new locator.
> 
> In other words: sessions move out of the state where their flow label  
> can't be reused for other sessions fairly quickly because either they  
> turn out shim-enabled and then we know the set of locators for which  
> the flow label must remain unique, or they turn out shim-incable and  
> the flow label can be reused for any other destination address.
> 

Delivery-date: Thu, 21 Apr 2005 11:33:28 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 13:33:13 +0200
To: marcelo bagnulo braun <[email-masked]>

On 21-apr-2005, at 13:11, marcelo bagnulo braun wrote:

>> But it's not just the overhead. The problem is that adding bytes  
>> to the packet increases the work that must be done per packet.  
>> This is also very bad.

> Ok, no arguing that extra overhead is bad, but keep in mind that  
> the overhead is only cause when there is a rehoming event i.e. that  
> the locator being carried is different from the ULID of the session.

You still need to work your way through each packet to see if there  
is a header, so it's still bad even if the header isn't there...

>> As I said before, the only thing needed to make the flow label  
>> usable for this, and without taking away from its other uses, is  
>> avoid reusing flow labels for sessions with an unknown shim6 status.

> Not sure if a agree here.
> I mean, are you cosnidering the case where new locators can be  
> added after the context has been established?

In general: yes. There may be some corner cases, though. Are you  
thinking about the situation where a locator that first belongs to  
one host later belongs to another host?

> I mean, the requirement is to verify that those context that have  
> intersecting locator set use different flow id values.

How can different associations have overlapping locator sets?

> so if you are assuming that we have an static set of locators, then  
> this is easy, since you can verify it when the session is established.

> However if you assume dynamic locator sets, then this is simply  
> impossible, since you cannot possible verify what will happen in  
> the future i.e. if some of the locators included in one context  
> won't be later on added to another context that has the same flow  
> id value associated.

But the problem only exists when we have communication with the  
locator in question beforehand. So what would have to happen is that  
there is shim6 communication between two hosts, but there is also  
communication from one host to a locator without shim6, and then that  
locator is bound to the existing shim6 association. I agree that this  
can happen, but only for a very limited time: either the shim6- 
agnostic session will start up shim6 negotiations, or the existing  
association will add the new locator.

In other words: sessions move out of the state where their flow label  
can't be reused for other sessions fairly quickly because either they  
turn out shim-enabled and then we know the set of locators for which  
the flow label must remain unique, or they turn out shim-incable and  
the flow label can be reused for any other destination address.

Delivery-date: Thu, 21 Apr 2005 11:26:49 +0000
Date: Thu, 21 Apr 2005 13:26:31 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Pekka Savola <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: flow label demultiplexing -- worst cases

Below...

Pekka Savola wrote:
> On Wed, 20 Apr 2005, Brian E Carpenter wrote:
> 
>>>>  - in step 3. above, an implementation could also perform two-tiered
>>>>    reservation: first reserve the flow label for any communication,
>>>>    but when in the danger of running out, start using it also for
>>>>    those destinations that don't belong to the locator set.  This way
>>>>    this would not be an issue (albeit difficult to debug) until the
>>>>    hosts are so loaded that they're running out of the flow label
>>>>    space for their sessions.
>>>
>>>
>>> seems the reasonable choice if the flow id approach imho
>>>
>>
>> Agree. In any case, I think the worst case result here is that
>> we trigger an unnecessary rehoming event because two flows
>> get overlaid somehow inside the shim6 state machine. Probably the
>> state machine description will need to cover this case, even though
>> it will be very rare.
> 
> 
> It isn't clearly obvious to me that this is the worst case (and what the 
> other cases are), so this needs to be analyzed.
> 
> Potential cases might be (all of them not applicable here, but in 
> general with demultiplexing):
> 
>  - rehoming between the particular IP addresses [part of a past,
>    present or future locator sets], possibly for a specific flow, does
>    not work
>  - the session is rehomed and re-mapped, but the packets are
>    demultiplexed to an unrelated flow, causing data corruption,
>    retransmissions or resetting of the session
>  - unncessary rehoming event
> 
> ....
> 
> Speaking of rehoming and remapping... it could also happen (unless 
> there's something in the transport protocols that prevents this kind of 
> reuse) that the source and destination would have two identical flows, 
> just between different IP addresses (but with the same protocol and port 
> numbers).  That is,
> 
>  src=1.2.3.4, srcport=1, dstport=2, dst=4.5.6.7
>  src=1.2.3.5, srcport=1, dstport=2, dst=4.5.6.8
> 
> .. now if one of the source addresses fails, and you end doing 
> remapping, I wonder how different forms of demultiplexing deal with this 
> case as well..

Obviously, this must not happen (and that takes care of your data
corruption concern above, too).

The way to stop it happening is to say that a given host, whatever
set of addresses it may be using, MUST NOT use duplicate port numbers.
Ambiguous port numbers are at least as evil as ambiguous addresses.

For implementors who virtualize IP addresses across a set of physical
or virtual servers, this is a slightly tricky condition to meet, but
they need to meet it anyway today, otherwise the kind of flow confusion
you fear is likely to happen. Shim6 doesn't create this problem.

btw your example above looks like IPv4 addresses. A mistake, I hope.

     Brian

Delivery-date: Thu, 21 Apr 2005 11:18:02 +0000
Date: Thu, 21 Apr 2005 13:17:48 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Jeroen Massar <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

I wonder if Jeroen is mixing the shim6 state establishment
protocol (which we have never discussed in detail) and the
context tag (which is explained in draft-ietf-multi6-l3shim-00.txt)?

And I don't know what a shim6 gateway is. Shim6 is basically
designed host-to-host.

    Brian

marcelo bagnulo braun wrote:
> 
> El 20/04/2005, a las 17:26, Jeroen Massar escribió:
> 
>>
>> Extension Header is IMHO the best step. Overloading the Flow label is
>> not a good idea, if we want that then we should bump the version of the
>> protocol and include this directly in the specification.
>>
>> Actually what would be preferred to me is to have a packet like:
>>
>> [ routing-src : 128bits / 16 bytes ]
>> [ routing-dst : 128bits / 16 bytes ]
>> [    site-src :  64bits /  8 bytes ]
>> [    site-dst :  64bits /  8 bytes ]
>>
>> This does indeed not allow 'host' multihoming but saves 8 complete
>> bytes. The site-src/dst could even be made optional in case the source
>> site supports shim6 but does not do any shim6 itself (or define src=::
>> to specify no translation?)
>>
> 
> I may be missing what is site-src and site-dst...
> 
> What i had in mind to carry in the extension header was just a context 
> tag, just a random value that can be used to identify the context 
> established between the peers. This context tag extension header needs 
> only to be included what the addresses carried in the packet differ from 
> the ULIDs associated with the context.
> 
> However, i feel that you have a different idea with this site-src and 
> site-dst... could you expand on this?
> 
> Regards, marcelo
> 
> 
>> And people, how much 'overhead' is 16 bytes on the many megabytes that
>> one will transfer? We are unfortunately not in the era anymore that
>> webdesigners simply make an HTML page it has to include a lot of images,
>> flash and other mumbo jumbo. As Marcelo mentions the above would only be
>> sent for the first packet using this pair of addresses.
>>
>> Also a shim6 gate can easily drop this extension header when doing the
>> de-multiplex/de-nat thus making this completely transparent for the
>> outer hosts. Maybe a creepy thing: multiple 'stacked' headers like these
>> and doing shim6-in-shim6... but let's forbid that 'feature' ;)
>>
>> Btw this comes awfully close to some space-port writeup I've seen once.
>>
>> Greets,
>>  Jeroen
>>
> 
> 
> 

Delivery-date: Thu, 21 Apr 2005 11:11:35 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label - the problem
Date: Thu, 21 Apr 2005 13:11:41 +0200
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

El 21/04/2005, a las 12:42, Iljitsch van Beijnum escribi=F3:
>
> 1. An extension header or destination option
> 2. "stolen bits"
> 3. Port numbers
> 4. The flow label
>
> I'm very much opposed to 1. because I think SOMEONE has to care about=20=

> the overhead/payload ratio. Don't forget we're already moving from 20=20=

> bytes for IPv4 to 40 bytes for IPv6. Then there is TCP which is=20
> another 20 bytes, the timestamp option that many OSes ALWAYS use=20
> regardless of whether it's appropriate (12 bytes) and of course lower=20=

> layer overhead. If you look at the web for instance you'll see that=20
> *many* pages use a plethora of 0.1 KB images. It costs several=20
> kilobytes in mostly HTTP overhead to request those images.
>
> But it's not just the overhead. The problem is that adding bytes to=20
> the packet increases the work that must be done per packet. This is=20
> also very bad.
>

Ok, no arguing that extra overhead is bad, but keep in mind that the=20
overhead is only cause when there is a rehoming event i.e. that the=20
locator being carried is different from the ULID of the session.

> (BTW using 128 bits or even 64 is way too many as you can't have=20
> lookup tables this large. 4 to 6 bytes would be more in line with 8=20
> more bytes in the header.)
>
...
>
> Then there is the flow label. This is pretty much an optimization of=20=

> case 3, with two added bonusses: the flow label can be found in a=20
> fixed place in the packet, and it applies to all transports.
>
> As I said before, the only thing needed to make the flow label usable=20=

> for this, and without taking away from its other uses, is avoid=20
> reusing flow labels for sessions with an unknown shim6 status.

Not sure if a agree here.
I mean, are you cosnidering the case where new locators can be added=20
after the context has been established?
I mean, the requirement is to verify that those context that have=20
intersecting locator set use different flow id values.

so if you are assuming that we have an static set of locators, then=20
this is easy, since you can verify it when the session is established.

However if you assume dynamic locator sets, then this is simply=20
impossible, since you cannot possible verify what will happen in the=20
future i.e. if some of the locators included in one context won't be=20
later on added to another context that has the same flow id value=20
associated.

Now what you can do is to simply assign different flow id values. the=20
problem is when you ran out of those. I guess we need to asses how=20
likely is the situation when a hosts run out of flow ids values, and=20
that there is an actual clashing of flow ids between session sharing=20
locators and what is the effect of this situation (probably the=20
addition of the repeated locator cannot be accepted in the other=20
session, i guess). Imho the critical point is to evaluate this trade=20
off here.

In addition there is the incapability of using previously unkown=20
locators directly in data packets (perhaps this could be addressed,=20
since the data packet would also have to contain validation infromation=20=

for the new locator, so proessing before the shim header would result=20
in adding the new locator to the locator set avaialble for the session)

Regards, marcelo

>  For known non-shim sessions the current rules apply and for known=20
> shim sessions the current rules also apply except that the full=20
> address sets for both ends must be considered one address for flow=20
> label selection purposes. Yes, this is a little more work but it's per=20=

> session rather than per packet so it's not so bad.
>

Delivery-date: Thu, 21 Apr 2005 10:43:37 +0000
To: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Flow label - the problem
Date: Thu, 21 Apr 2005 12:42:54 +0200

You guys are making all of this WAY too difficult.

The problem we have to deal with is the possibilities of two  
transport-level sessions that share the same shim6 association using  
different ULIDs.

One way to deal with this is to forbid it. So implementations would  
have to choose source and destination ULIDs and stick with those for  
any particular shim6 association. However, this is bad for load  
balancing and it's possible that two sessions to different ULIDs turn  
out to terminate on the same host unexpectedly, in which case a full  
shim6 association wouldn't be able to form.

However, a good way to enforce this is to disallow overlap between  
ULIDs and additional locators. So if a host sees prefixes A and B, it  
forms four addresses:

A::ULID
A::locator-for-B
B::ULID
B::locator-for-A

Another way is to allow more than a single shim6 association at one  
time between two hosts, or to have transport sessions with different  
ULIDs within a single association. In this case there are four ways  
to determine the right ULID set:

1. An extension header or destination option
2. "stolen bits"
3. Port numbers
4. The flow label

I'm very much opposed to 1. because I think SOMEONE has to care about  
the overhead/payload ratio. Don't forget we're already moving from 20  
bytes for IPv4 to 40 bytes for IPv6. Then there is TCP which is  
another 20 bytes, the timestamp option that many OSes ALWAYS use  
regardless of whether it's appropriate (12 bytes) and of course lower  
layer overhead. If you look at the web for instance you'll see that  
*many* pages use a plethora of 0.1 KB images. It costs several  
kilobytes in mostly HTTP overhead to request those images.

But it's not just the overhead. The problem is that adding bytes to  
the packet increases the work that must be done per packet. This is  
also very bad.

(BTW using 128 bits or even 64 is way too many as you can't have  
lookup tables this large. 4 to 6 bytes would be more in line with 8  
more bytes in the header.)

Erik has looked at stealing bits from the protocol field. The problem  
is that this isn't very clean and the number of bits that can be  
found this way is small. The main advantage would be to be able to  
have routers rewrite addresses, but that's not on the table right now.

Looking at the port numbers is quite natural especially in an  
integrated tcp/ip implementation where this needs to happen at some  
point anway. The trouble is that not all protocols have and/or expose  
protocol numbers. For IPsec there is the SA of course, but there are  
some protocols that don't have anything equivalent. However, some  
limitations for these protocols would presumably be acceptable if it  
means good performance for TCP, UDP and other more common transports.

Then there is the flow label. This is pretty much an optimization of  
case 3, with two added bonusses: the flow label can be found in a  
fixed place in the packet, and it applies to all transports.

As I said before, the only thing needed to make the flow label usable  
for this, and without taking away from its other uses, is avoid  
reusing flow labels for sessions with an unknown shim6 status. For  
known non-shim sessions the current rules apply and for known shim  
sessions the current rules also apply except that the full address  
sets for both ends must be considered one address for flow label  
selection purposes. Yes, this is a little more work but it's per  
session rather than per packet so it's not so bad.

Delivery-date: Wed, 20 Apr 2005 21:47:44 +0000
Date: Thu, 21 Apr 2005 00:46:36 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: flow label demultiplexing -- worst cases

On Wed, 20 Apr 2005, Brian E Carpenter wrote:
>>>  - in step 3. above, an implementation could also perform two-tiered
>>>    reservation: first reserve the flow label for any communication,
>>>    but when in the danger of running out, start using it also for
>>>    those destinations that don't belong to the locator set.  This way
>>>    this would not be an issue (albeit difficult to debug) until the
>>>    hosts are so loaded that they're running out of the flow label
>>>    space for their sessions.
>> 
>> seems the reasonable choice if the flow id approach imho
>> 
>
> Agree. In any case, I think the worst case result here is that
> we trigger an unnecessary rehoming event because two flows
> get overlaid somehow inside the shim6 state machine. Probably the
> state machine description will need to cover this case, even though
> it will be very rare.

It isn't clearly obvious to me that this is the worst case (and what 
the other cases are), so this needs to be analyzed.

Potential cases might be (all of them not applicable here, but in 
general with demultiplexing):

  - rehoming between the particular IP addresses [part of a past,
    present or future locator sets], possibly for a specific flow, does
    not work
  - the session is rehomed and re-mapped, but the packets are
    demultiplexed to an unrelated flow, causing data corruption,
    retransmissions or resetting of the session
  - unncessary rehoming event

....

Speaking of rehoming and remapping... it could also happen (unless 
there's something in the transport protocols that prevents this kind 
of reuse) that the source and destination would have two identical 
flows, just between different IP addresses (but with the same protocol 
and port numbers).  That is,

  src=1.2.3.4, srcport=1, dstport=2, dst=4.5.6.7
  src=1.2.3.5, srcport=1, dstport=2, dst=4.5.6.8

.. now if one of the source addresses fails, and you end doing 
remapping, I wonder how different forms of demultiplexing deal with 
this case as well..

-- 
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: Wed, 20 Apr 2005 19:44:09 +0000
Date: Wed, 20 Apr 2005 22:43:13 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: [email-masked]
Subject: Re: flow label demultiplexing

On Mon, 18 Apr 2005, Iljitsch van Beijnum wrote:
>> Now, multihoming context is exchanged.
>
>> After that, the host tries to establish a new flow from 2001::1 to 
>> 2002::B2; unless there is reservation, it could end up picking "1" as well, 
>> which could create issues when either 2002::B1 or 2002::B2 fails because 
>> the flow labels overlap.
>
> Hm this isn't how current implementations work. They pick a more or less 
> random flow label for each new session. This is encouraged because it makes 
> for better hash bucket utilization in boxes that want to do something useful 
> with the flow label.

Sure.  But the spec allows incremental assignment of flow labels in 
addition to a random process; heck, even recommends it.  It just 
recommends that the start of the counter is randomized at startup.

However, there's still a MUST requirement that the flow label must not 
clash with existing or recently used ones.  So, you can't just 
randomize and hope it's OK. (I'm not sure if implementations check 
this.)

> For multihoming, we would probably want to use the same flow label instead in 
> order to reuse a previously established context. If having all sessions 
> between two hosts use the same flow label is undesirable, it may be necessary 
> to tie the multihoming state to ranges of flow labels rather than a single 
> one...

My assumption definitely is that requiring all the communications 
between two shim6 hosts use the same flow label is a non-starter (if 
not otherwise, but that would eliminate all other use of flow label on 
those hosts).  This isn't stated explicitly in the document, so maybe 
it should be.

However, what I was assuming is that if the flow label is used, it 
would be used to make sure sessions are uniquely identified across the 
locator sets, so that by knowing the locators, you'd know whether an 
incoming packet should be mapped to an existing context or whether 
it's a new session.

>> Of course, there is still a race condition between the communication is 
>> established and the multihoming context is set up -- there's no way to do 
>> the reservation for destination locators before you know which ones they 
>> are.
>
> Ok so you're saying a user visits a website at www.ietf.org and the html 
> links to an image on images.ietf.org, both have addresses 2001::1 and 2002::2 
> and due to DNS load balancing the session to www uses 2001::1 and the one to 
> images 2002::2. Then, when the sessions are set up with the same flow label 
> for each, the shim does its thing and...? The sessions will be merged into a 
> single association so there isn't a problem, I'd think. Rather the opposite: 
> normal behavior would 99.9999% (yes I counted the nines) sure result in two 
> different flow labels but now there is one association with two flow 
> labels... But that shouldn't be too problematic.
>
> In any event, you wouldn't want to reuse the same flow label any time soon 
> irrespective of the addresses.

No, I'm worried about the contrary -- that the demultiplexing host 
thinks a packet belongs to a context, and demultiplexes it there, but 
it actually doesn't, and results in the corrupted data (e.g., with 
UDP) or maybe a TCP reset.

So, AFAICS, you can't just "merge" different sessions between two 
different hosts.

>> However, I would be interested in hearing if you have ideas what the 
>> protocol should do after narrowing the flow label down to 3 or 4.  How does 
>> it disambiguate further from those 3 or 4?  Would you rely on the 
>> implementation taking a peek at (say) layer 4 headers or some other 
>> information?
>
> There are two obvious options:
>
> 1. The flow label is relevant regardless of the addresses: this can't work 
> because of the possibility of clashes with flow labels in unrelated packets
>
> 2. The flow label is only relevant with certain source/dest address 
> combinations: but what's the additional benefit of the flow label here, we 
> can demultiplex on the addresses
>
> I guess the only way the flow label could be useful is as a last resort to 
> correlate packets with unknown addresses to existing sessions. But this is 
> insecure, so we need to trigger some kind of negotiation to get to know the 
> unknown addresses. This could still be somewhat useful because if we're 99% 
> sure who we're talking to we can do a one RTT challenge/response rather than 
> something more involved.

I don't think these help in narrowing the flow label down further.  My 
assumption (as I tried to describe) is that option 1 is definitely 
out.

For 2, I have different assumption.  I'd assume that in most cases you 
actually _do_ know the source/dest address combinations; i.e., every 
shim6 host, when the context has been exchanged, keeps track of all 
the locators of the peer.  Flow label is just used to disambiguate 
between the separate sessions between these combinations.

-- 
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: Wed, 20 Apr 2005 15:43:44 +0000
Date: Wed, 20 Apr 2005 17:43:18 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Flow label versus Extension header

marcelo bagnulo braun wrote:
...
> The dificulties with the Extension header is clear, i guess:
> - overhead. However, it must be noted that this overhead only occurs 
> when there have been a rehoming event, i.e. when no rehoming has 
> occurred, no need for the extension header in data packets, since there 
> is no need to demultiplex.
> the benefit of this approach is that is cleaner and that is probably 
> simpler (since we can use a 128 bit context tag, making sure that is 
> unique)
> 
> Any additional considerations?

Payload MTU size will be reduced for the packets carrying the extension
header. But I think that is a small price to pay for a clean solution.

    Brian

Delivery-date: Wed, 20 Apr 2005 15:35:51 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Flow label versus Extension header
Date: Wed, 20 Apr 2005 17:35:55 +0200
To: Jeroen Massar <[email-masked]>

El 20/04/2005, a las 17:26, Jeroen Massar escribi=F3:
>
> Extension Header is IMHO the best step. Overloading the Flow label is
> not a good idea, if we want that then we should bump the version of =
the
> protocol and include this directly in the specification.
>
> Actually what would be preferred to me is to have a packet like:
>
> [ routing-src : 128bits / 16 bytes ]
> [ routing-dst : 128bits / 16 bytes ]
> [    site-src :  64bits /  8 bytes ]
> [    site-dst :  64bits /  8 bytes ]
>
> This does indeed not allow 'host' multihoming but saves 8 complete
> bytes. The site-src/dst could even be made optional in case the source
> site supports shim6 but does not do any shim6 itself (or define src=3D::=

> to specify no translation?)
>

I may be missing what is site-src and site-dst...

What i had in mind to carry in the extension header was just a context=20=

tag, just a random value that can be used to identify the context=20
established between the peers. This context tag extension header needs=20=

only to be included what the addresses carried in the packet differ=20
from the ULIDs associated with the context.

However, i feel that you have a different idea with this site-src and=20
site-dst... could you expand on this?

Regards, marcelo

> And people, how much 'overhead' is 16 bytes on the many megabytes that
> one will transfer? We are unfortunately not in the era anymore that
> webdesigners simply make an HTML page it has to include a lot of=20
> images,
> flash and other mumbo jumbo. As Marcelo mentions the above would only=20=

> be
> sent for the first packet using this pair of addresses.
>
> Also a shim6 gate can easily drop this extension header when doing the
> de-multiplex/de-nat thus making this completely transparent for the
> outer hosts. Maybe a creepy thing: multiple 'stacked' headers like=20
> these
> and doing shim6-in-shim6... but let's forbid that 'feature' ;)
>
> Btw this comes awfully close to some space-port writeup I've seen =
once.
>
> Greets,
>  Jeroen
>

Delivery-date: Wed, 20 Apr 2005 15:26:47 +0000
Subject: Re: Flow label versus Extension header
From: Jeroen Massar <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: shim6 <[email-masked]>
Organization: Unfix
Date: Wed, 20 Apr 2005 17:26:22 +0200

--=-PHZeV7Jf/CCJxuNJme5F
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-04-20 at 16:43 +0200, marcelo bagnulo braun wrote:
> Hi,
>=20
> continuing with the topic initiated by Pekka, i guess that the next=20
> item to discuss is whether is better to carry the context tag in the=20
> flow id or in a new Extension header.

<SNIP>

> The dificulties with the Extension header is clear, i guess:
> - overhead. However, it must be noted that this overhead only occurs=20
> when there have been a rehoming event, i.e. when no rehoming has=20
> occurred, no need for the extension header in data packets, since there=20
> is no need to demultiplex.
> the benefit of this approach is that is cleaner and that is probably=20
> simpler (since we can use a 128 bit context tag, making sure that is=20
> unique)
>=20
> Any additional considerations?

Extension Header is IMHO the best step. Overloading the Flow label is
not a good idea, if we want that then we should bump the version of the
protocol and include this directly in the specification.

Actually what would be preferred to me is to have a packet like:

[ routing-src : 128bits / 16 bytes ]
[ routing-dst : 128bits / 16 bytes ]
[    site-src :  64bits /  8 bytes ]
[    site-dst :  64bits /  8 bytes ]

This does indeed not allow 'host' multihoming but saves 8 complete
bytes. The site-src/dst could even be made optional in case the source
site supports shim6 but does not do any shim6 itself (or define src=3D::
to specify no translation?)

And people, how much 'overhead' is 16 bytes on the many megabytes that
one will transfer? We are unfortunately not in the era anymore that
webdesigners simply make an HTML page it has to include a lot of images,
flash and other mumbo jumbo. As Marcelo mentions the above would only be
sent for the first packet using this pair of addresses.

Also a shim6 gate can easily drop this extension header when doing the
de-multiplex/de-nat thus making this completely transparent for the
outer hosts. Maybe a creepy thing: multiple 'stacked' headers like these
and doing shim6-in-shim6... but let's forbid that 'feature' ;)

Btw this comes awfully close to some space-port writeup I've seen once.

Greets,
 Jeroen

--=-PHZeV7Jf/CCJxuNJme5F
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-PHZeV7Jf/CCJxuNJme5F--

Delivery-date: Wed, 20 Apr 2005 14:43:58 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Flow label versus Extension header
Date: Wed, 20 Apr 2005 16:43:48 +0200

Hi,

continuing with the topic initiated by Pekka, i guess that the next 
item to discuss is whether is better to carry the context tag in the 
flow id or in a new Extension header.

As has been pointed out in the previous thread, the difficulties with 
flow id are:
- There is the possibility of running out of flow ids values and that 
at some point, it is not possible to accept a locator being added to an 
established context because it would turn impossible to demultiplex. 
the probability of this happening is quite low though, imho
- The locator set must be known before hand, since the information used 
for demux is src, dst and flow id in the general case. Probably, in 
most cases using only the flow id is good enough if we follow the rules 
of assigning the flow id suggested by Pekka, but this cannot be assured 
in the general case. This may be problem in the case that new locators 
are available and that all the previous locators are no longer 
available (The situation where this could happen is when mobility comes 
into play) ( An additional question here is whether we need to assign a 
flow  id value per direction in the communication, or in other words, 
if there is a single flow id for both directions of the communication, 
then who picks up the flow id? what if the flow id is already being 
used by the other host in another context?)
- We are overloading a field that is supposed to be used for something 
else, i guess, so perhaps we may end up with incompatible usages??

The dificulties with the Extension header is clear, i guess:
- overhead. However, it must be noted that this overhead only occurs 
when there have been a rehoming event, i.e. when no rehoming has 
occurred, no need for the extension header in data packets, since there 
is no need to demultiplex.
the benefit of this approach is that is cleaner and that is probably 
simpler (since we can use a 128 bit context tag, making sure that is 
unique)

Any additional considerations?

Regards, marcelo

Delivery-date: Wed, 20 Apr 2005 12:07:34 +0000
Date: Wed, 20 Apr 2005 14:06:57 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: flow label demultiplexing

marcelo bagnulo braun wrote:
> 
> El 19/04/2005, a las 16:15, Iljitsch van Beijnum escribió:
> 
>> On 19-apr-05, at 15:35, marcelo bagnulo braun wrote:
>>
>>>> If we want to use the flow label for this we only need to change the 
>>>> flow label sematics every so slightly so the flow label is unique 
>>>> for a set of source/dest locators belonging to the same source and 
>>>> dest hosts rather than source/dest addresses. Not too unreasonable, 
>>>> IMO.
>>
>>
>>> Right, but i guess that what Pekka was pointing out is that, in the 
>>> case that the locator set are dynamic, you don't know when the 
>>> locator set will overlap in the future (because an locator that is 
>>> already present in one context is added to another one in the 
>>> future), so it is not possible to make sure that the flow id is not 
>>> repeated in two different contexts whose locator set overlap. Hence 
>>> the problem.
>>
>>
>> Well, there are 1048575 possible flow label values so it's not 
>> necessary to reuse the same one for a new session all that quickly. 
>> The limitation is that the same flow label can't be used for a 
>> different session to the same shim-enabled destination host 
>> (regardless of address), for sessions to the same source/dest address 
>> pair for non-shim-enabled hosts and for sessions to ANY host where the 
>> shim-enabled status is unknown. Since presumably, we're going to find 
>> out whether a certain correspondent host is shim-enabled or not sooner 
>> rather than later, I don't see how this set of limitations can lead to 
>> trouble other than the general downside of adding some complexity.
>>
> 
> so quoting Pekka's initial mail on the thread:
> 
>>  - in step 3. above, an implementation could also perform two-tiered
>>    reservation: first reserve the flow label for any communication,
>>    but when in the danger of running out, start using it also for
>>    those destinations that don't belong to the locator set.  This way
>>    this would not be an issue (albeit difficult to debug) until the
>>    hosts are so loaded that they're running out of the flow label
>>    space for their sessions.
>>
> 
> seems the reasonable choice if the flow id approach imho
> 

Agree. In any case, I think the worst case result here is that
we trigger an unnecessary rehoming event because two flows
get overlaid somehow inside the shim6 state machine. Probably the
state machine description will need to cover this case, even though
it will be very rare.

    Brian

Delivery-date: Tue, 19 Apr 2005 14:25:44 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 16:25:51 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 19/04/2005, a las 16:15, Iljitsch van Beijnum escribi=F3:

> On 19-apr-05, at 15:35, marcelo bagnulo braun wrote:
>
>>> If we want to use the flow label for this we only need to change the=20=

>>> flow label sematics every so slightly so the flow label is unique=20
>>> for a set of source/dest locators belonging to the same source and=20=

>>> dest hosts rather than source/dest addresses. Not too unreasonable,=20=

>>> IMO.
>
>> Right, but i guess that what Pekka was pointing out is that, in the=20=

>> case that the locator set are dynamic, you don't know when the=20
>> locator set will overlap in the future (because an locator that is=20
>> already present in one context is added to another one in the=20
>> future), so it is not possible to make sure that the flow id is not=20=

>> repeated in two different contexts whose locator set overlap. Hence=20=

>> the problem.
>
> Well, there are 1048575 possible flow label values so it's not=20
> necessary to reuse the same one for a new session all that quickly.=20
> The limitation is that the same flow label can't be used for a=20
> different session to the same shim-enabled destination host=20
> (regardless of address), for sessions to the same source/dest address=20=

> pair for non-shim-enabled hosts and for sessions to ANY host where the=20=

> shim-enabled status is unknown. Since presumably, we're going to find=20=

> out whether a certain correspondent host is shim-enabled or not sooner=20=

> rather than later, I don't see how this set of limitations can lead to=20=

> trouble other than the general downside of adding some complexity.
>

so quoting Pekka's initial mail on the thread:

>  - in step 3. above, an implementation could also perform two-tiered
>    reservation: first reserve the flow label for any communication,
>    but when in the danger of running out, start using it also for
>    those destinations that don't belong to the locator set.  This way
>    this would not be an issue (albeit difficult to debug) until the
>    hosts are so loaded that they're running out of the flow label
>    space for their sessions.
>

seems the reasonable choice if the flow id approach imho

regards, marcelo

> Iljitsch
>

Delivery-date: Tue, 19 Apr 2005 14:15:43 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 16:15:18 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-apr-05, at 15:35, marcelo bagnulo braun wrote:

>> If we want to use the flow label for this we only need to change the 
>> flow label sematics every so slightly so the flow label is unique for 
>> a set of source/dest locators belonging to the same source and dest 
>> hosts rather than source/dest addresses. Not too unreasonable, IMO.

> Right, but i guess that what Pekka was pointing out is that, in the 
> case that the locator set are dynamic, you don't know when the locator 
> set will overlap in the future (because an locator that is already 
> present in one context is added to another one in the future), so it 
> is not possible to make sure that the flow id is not repeated in two 
> different contexts whose locator set overlap. Hence the problem.

Well, there are 1048575 possible flow label values so it's not 
necessary to reuse the same one for a new session all that quickly. The 
limitation is that the same flow label can't be used for a different 
session to the same shim-enabled destination host (regardless of 
address), for sessions to the same source/dest address pair for 
non-shim-enabled hosts and for sessions to ANY host where the 
shim-enabled status is unknown. Since presumably, we're going to find 
out whether a certain correspondent host is shim-enabled or not sooner 
rather than later, I don't see how this set of limitations can lead to 
trouble other than the general downside of adding some complexity.

Iljitsch

Delivery-date: Tue, 19 Apr 2005 13:35:49 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 15:35:46 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 19/04/2005, a las 15:00, Iljitsch van Beijnum escribi=F3:

> On 19-apr-05, at 14:51, marcelo bagnulo braun wrote:
>
>>> Under what circumstances would having different associations between=20=

>>> the same source and destination locator sets be necessary and/or=20
>>> useful?
>
>> Well, i think they may occur pretty naturally, and that we probably=20=

>> need to do something in order to avoid it from happening. Correct me=20=

>> if i wrong in the next scenario:
>
>> Node A has IPA1 and IPA2
>> Node B has IPB
>
>> Two communications are initiated between the nodes. Because no=20
>> address is preselected, one of the communications is using IPA1 and=20=

>> IPB as ULIDs and the other one is using IPA2 and IPB as ULIDs. Now an=20=

>> outage occurs affecting IPA1 and the communication involving IPA1 and=20=

>> IPB is moved to the alternative locator i.e. IPA2.
>
>> At this point, packets corresponding to any of the communications=20
>> contain the same addresses, IPA2 and IPB, and they need to be=20
>> demultiplexed.
>
> Yes, this is a good example. So:
>
> - demultiplexing packets to the right association can very likely be=20=

> done based on the address pair, but
> - demultiplexing packets to the right ULIDs can't be done on addresses=20=

> alone, either this must be done based on higher layer information, the=20=

> flow label or something new
>
> If we want to use the flow label for this we only need to change the=20=

> flow label sematics every so slightly so the flow label is unique for=20=

> a set of source/dest locators belonging to the same source and dest=20
> hosts rather than source/dest addresses. Not too unreasonable, IMO.
>
>

Right, but i guess that what Pekka was pointing out is that, in the=20
case that the locator set are dynamic, you don't know when the locator=20=

set will overlap in the future (because an locator that is already=20
present in one context is added to another one in the future), so it is=20=

not possible to make sure that the flow id is not repeated in two=20
different contexts whose locator set overlap. Hence the problem.

Regards, marcelo

Delivery-date: Tue, 19 Apr 2005 13:00:28 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 15:00:20 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-apr-05, at 14:51, marcelo bagnulo braun wrote:

>> Under what circumstances would having different associations between 
>> the same source and destination locator sets be necessary and/or 
>> useful?

> Well, i think they may occur pretty naturally, and that we probably 
> need to do something in order to avoid it from happening. Correct me 
> if i wrong in the next scenario:

> Node A has IPA1 and IPA2
> Node B has IPB

> Two communications are initiated between the nodes. Because no address 
> is preselected, one of the communications is using IPA1 and IPB as 
> ULIDs and the other one is using IPA2 and IPB as ULIDs. Now an outage 
> occurs affecting IPA1 and the communication involving IPA1 and IPB is 
> moved to the alternative locator i.e. IPA2.

> At this point, packets corresponding to any of the communications 
> contain the same addresses, IPA2 and IPB, and they need to be 
> demultiplexed.

Yes, this is a good example. So:

- demultiplexing packets to the right association can very likely be 
done based on the address pair, but
- demultiplexing packets to the right ULIDs can't be done on addresses 
alone, either this must be done based on higher layer information, the 
flow label or something new

If we want to use the flow label for this we only need to change the 
flow label sematics every so slightly so the flow label is unique for a 
set of source/dest locators belonging to the same source and dest hosts 
rather than source/dest addresses. Not too unreasonable, IMO.

Delivery-date: Tue, 19 Apr 2005 12:57:54 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 14:57:55 +0200
To: marcelo bagnulo braun <[email-masked]>

Minor correction...

El 19/04/2005, a las 14:51, marcelo bagnulo braun escribi=F3:

>
> El 19/04/2005, a las 13:17, Iljitsch van Beijnum escribi=F3:
>
>> On 19-apr-05, at 11:46, marcelo bagnulo braun wrote:
>>
>>>> There are two obvious options:
>>
>>>> 1. The flow label is relevant regardless of the addresses: this=20
>>>> can't work because of the possibility of clashes with flow labels=20=

>>>> in unrelated packets
>>>> 2. The flow label is only relevant with certain source/dest address=20=

>>>> combinations: but what's the additional benefit of the flow label=20=

>>>> here, we can demultiplex on the addresses
>>
>>> Well, there could packets with the same src and dst address, that=20
>>> belong to different communications with different ULIDs, right? the=20=

>>> flow label is to determine the proper demux context.
>>
>> Under what circumstances would having different associations between=20=

>> the same source and destination locator sets be necessary and/or=20
>> useful?
>>
>>
> Well, i think they may occur pretty naturally, and that we probably=20
> need to do something in order to avoid it from happening.

this is not exactly what i meant... what i mean is that this situation=20=

would occur unless the protocol is designed in a way to avoid it. I am=20=

not advocating for avoiding it though....

Sorry for the wording...

marcelo

> Correct me if i wrong in the next scenario:
>
> Node A has IPA1 and IPA2
> Node B has IPB
>
> Two communications are initiated between the nodes. Because no address=20=

> is preselected, one of the communications is using IPA1 and IPB as=20
> ULIDs and the other one is using IPA2 and IPB as ULIDs. Now an outage=20=

> occurs affecting IPA1 and the communication involving IPA1 and IPB is=20=

> moved to the alternative locator i.e. IPA2.
>
> At this point, packets corresponding to any of the communications=20
> contain the same addresses, IPA2 and IPB, and they need to be=20
> demultiplexed.
>
> I guess we could came up with more complex scenarios where the=20
> locators used are not being used as ULIDs in any of the established=20
> communications.
>
> Makes sense?
>
> regards, marcelo
>
>

Delivery-date: Tue, 19 Apr 2005 12:52:10 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 14:51:55 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 19/04/2005, a las 13:17, Iljitsch van Beijnum escribi=F3:

> On 19-apr-05, at 11:46, marcelo bagnulo braun wrote:
>
>>> There are two obvious options:
>
>>> 1. The flow label is relevant regardless of the addresses: this=20
>>> can't work because of the possibility of clashes with flow labels in=20=

>>> unrelated packets
>>> 2. The flow label is only relevant with certain source/dest address=20=

>>> combinations: but what's the additional benefit of the flow label=20
>>> here, we can demultiplex on the addresses
>
>> Well, there could packets with the same src and dst address, that=20
>> belong to different communications with different ULIDs, right? the=20=

>> flow label is to determine the proper demux context.
>
> Under what circumstances would having different associations between=20=

> the same source and destination locator sets be necessary and/or=20
> useful?
>
>
Well, i think they may occur pretty naturally, and that we probably=20
need to do something in order to avoid it from happening. Correct me if=20=

i wrong in the next scenario:

Node A has IPA1 and IPA2
Node B has IPB

Two communications are initiated between the nodes. Because no address=20=

is preselected, one of the communications is using IPA1 and IPB as=20
ULIDs and the other one is using IPA2 and IPB as ULIDs. Now an outage=20
occurs affecting IPA1 and the communication involving IPA1 and IPB is=20
moved to the alternative locator i.e. IPA2.

At this point, packets corresponding to any of the communications=20
contain the same addresses, IPA2 and IPB, and they need to be=20
demultiplexed.

I guess we could came up with more complex scenarios where the locators=20=

used are not being used as ULIDs in any of the established=20
communications.

Makes sense?

regards, marcelo

Delivery-date: Tue, 19 Apr 2005 11:17:43 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 13:17:34 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-apr-05, at 11:46, marcelo bagnulo braun wrote:

>> There are two obvious options:

>> 1. The flow label is relevant regardless of the addresses: this can't 
>> work because of the possibility of clashes with flow labels in 
>> unrelated packets
>> 2. The flow label is only relevant with certain source/dest address 
>> combinations: but what's the additional benefit of the flow label 
>> here, we can demultiplex on the addresses

> Well, there could packets with the same src and dst address, that 
> belong to different communications with different ULIDs, right? the 
> flow label is to determine the proper demux context.

Under what circumstances would having different associations between 
the same source and destination locator sets be necessary and/or 
useful?

Delivery-date: Tue, 19 Apr 2005 11:13:33 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 13:13:05 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-apr-05, at 11:04, marcelo bagnulo braun wrote:

> In order to prevent flooding, i guess that the easiest way if to 
> preform a reachability test to the address, in order to find out if 
> the target is willing to receive packets.
> At this point, an interesting question is raised: do we need to 
> perform the reachability test in order to receive packets or is it 
> enough to perform the reachability test before sending packets to the 
> new locator?

I think for the security stuff it makes sense to delay the return 
routability check. On the other hand, we also have to worry about 
finding reasonably good paths and avoiding ingress filtering trouble. 
Doing an exhaustive search for the best locator pair at any point leads 
to excessive traffic (and delays), though. A good alternative could be 
to find a single working and/or good enough backup address pair after 
the initial shim startup exchange. In many cases this will allow fast 
failover to a working backup pair when there is an outage with only a 
relatively low amount of additional traffic.

Also, doing this for several associations allows a host to draw 
conclusions about its connectivity that can be helpful in selecting a 
more optimal first address to try both for regular sessions and for 
candidate backup pairs.

Delivery-date: Tue, 19 Apr 2005 09:46:15 +0000
Cc: Pekka Savola <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 11:46:19 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 18/04/2005, a las 18:23, Iljitsch van Beijnum escribi=F3:
>> This is a good point, and I don't recall seeing it in the draft.
>
>> However, I would be interested in hearing if you have ideas what the=20=

>> protocol should do after narrowing the flow label down to 3 or 4. =20
>> How does it disambiguate further from those 3 or 4?  Would you rely=20=

>> on the implementation taking a peek at (say) layer 4 headers or some=20=

>> other information?
>
> There are two obvious options:
>
> 1. The flow label is relevant regardless of the addresses: this can't=20=

> work because of the possibility of clashes with flow labels in=20
> unrelated packets
> 2. The flow label is only relevant with certain source/dest address=20
> combinations: but what's the additional benefit of the flow label=20
> here, we can demultiplex on the addresses
>

Well, there could packets with the same src and dst address, that=20
belong to different communications with different ULIDs, right? the=20
flow label is to determine the proper demux context.

Regards, marcelo

> I guess the only way the flow label could be useful is as a last=20
> resort to correlate packets with unknown addresses to existing=20
> sessions. But this is insecure, so we need to trigger some kind of=20
> negotiation to get to know the unknown addresses. This could still be=20=

> somewhat useful because if we're 99% sure who we're talking to we can=20=

> do a one RTT challenge/response rather than something more involved.
>
> Or maybe I'm just going down the wrong path here... Why do we need a=20=

> bit in the IP header again?
>
>

Delivery-date: Tue, 19 Apr 2005 09:10:28 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 11:10:37 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 18/04/2005, a las 18:54, Iljitsch van Beijnum escribi=F3:

> On 18-apr-05, at 18:21, marcelo bagnulo braun wrote:
>
>> So, when you use CGA capabilities of the address, the CGA parameter=20=

>> data structure is exchanged upfront and it contains the public key.
>
>> Next, the node can use a new address (that was not included in the=20
>> CGA parameter data structure) because it can authorize it by signing=20=

>> it with the private key corresponding to the CGA. Moreover, such=20
>> signature could even be included in a packet that contains the new=20
>> address as source address (i think)
>
> But what exactly is signed here? I guess the whole packet, including=20=

> the source address.

As i understand it, the new locator introduced in the set need to be=20
signed. I guess we will need to add some additional context information=20=

to avoid reply attacks, and so one, but basically, the new alternative=20=

locator is signed with the private key associated to the CGA being used=20=

as identifier

>  A man in the middle would be able to modify anything that isn't=20
> signed. And even then, accepting a packet from an unknown source is=20
> dangerous because it can lead to a DoS against the CPU.

but i am not sure you could avoid DoS attacks from on path attacker...=20=

i mean, as soon the attacker discovers the context tag, he will be able=20=

t make the peer to verify some signatures, even though these don't=20
verify, right? I mean, if we use public key technology, i guess there=20
will risk of on path attackers dosing....

>
> A system where the receiver challenges the sender would be MUCH better=20=

> because that way we have return routability before spending serious=20
> CPU time.
>

Yes, this would make things better w.r.t. to on path dosers.... i guess=20=

it has the cost that you need to perform the reachability test before=20
accepting packets from unverified locators, which may add extra=20
latency.
I guess is part of the tradeoffs we need to start evaluating.

Regards, marcelo

>

Delivery-date: Tue, 19 Apr 2005 09:04:53 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Tue, 19 Apr 2005 11:04:46 +0200
To: Pekka Savola <[email-masked]>

El 18/04/2005, a las 22:27, Pekka Savola escribi=F3:

> On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
>>> Note that HBA+CGA in one doesn't help (AFAICS) because otherwise=20
>>> you'd be trusting anyone you have a public key with to not hijack=20
>>> any of your sessions?
>>
>> Well, i guess not.
>>
>> In the CGA case, the address being used as the ULID for the=20
>> communication is a CGA that contains a hash of the publich key in the=20=

>> iid. In this case, you will only trust a public key whose hash=20
>> matches the iid of the ulid.
>
> Sure.
>
>> So, when you use CGA capabilities of the address, the CGA parameter=20=

>> data structure is exchanged upfront and it contains the public key.
>>
>> Next, the node can use a new address (that was not included in the=20
>> CGA parameter data structure) because it can authorize it by signing=20=

>> it with the private key corresponding to the CGA. Moreover, such=20
>> signature could even be included in a packet that contains the new=20
>> address as source address (i think)
>>
>> I mean, with CGA there is no need to know the addresses before hand.
>
> OK, I guess you'll assume that

>  1) the CGA implementations would check the prefix, i.e., that anyone=20=

> who claims to be of prefix A::/64 has a certificate to use that=20
> prefix, and can present that?

No, i am not assuming this.

>   Otherwise you trusting me would allow me to say I'm in control of a=20=

> third party's prefix, right?
>

Not a prefix, but just an address of that prefix, right?

I mean, through this message, the mh node is saying that this new=20
address (of a different previously unknow prefix) is his current=20
locator. but see below, becuase i guess we may be misunderstanding each=20=

other...

>  2) delegation path discovery works across the internet so you can=20
> actually find a common trust anchor, and
>

I am certainly not assuming this...

>  3) you sign the whole [shim6 exchange, and in this case everything,=20=

> if it's piggybacked] packet.  But CGA is only defined for neighbor=20
> discovery options...
>

I am certainly assuming that we are signing the alternative locator=20
information carried in a SHIM message using the private key of the CGA.=20=

Agree that this is not a usage that is currently defined for CGAs, but=20=

i guess that could be defined within the SHIM protocol

> As such, embedding the public key in the CGA/HBA address protects=20
> against the third parties trying to spoof another person's identity,=20=

> but does not protect against the responder lying.

Right.

Now, my understanding of this is the following:

We need to prevent basically two types of redirection attacks:=20
hijacking and flooding (this is basically what the threat analysis=20
says)

Now, using CGAs (or HBAs) basically, hijacking protection is achieved.
In order to prevent flooding, i guess that the easiest way if to=20
preform a reachability test to the address, in order to find out if the=20=

target is willing to receive packets.
At this point, an interesting question is raised: do we need to perform=20=

the reachability test in order to receive packets or is it enough to=20
perform the reachability test before sending packets to the new=20
locator?

As far as i understand, it would be safe enough to accept packets=20
perfoming only the CGA (or HBA) verification and delaying the=20
reachability test untli there is a need to send packets. This is so=20
becuase, the reachability test is used to prevent flooding attacks,=20
i.e. we need to do it before sending packets to that locator.
  Such configuration would allow to receive packets from previously=20
unknown locators, delaying the rechability verification until we need=20
to send packets to those locators.

make sense?

Regards, marcelo

>  (This is really bad if one would use something like opportunistic=20
> encryption rather than real "he's my very good friend, he won't try=20
> tricks" trust.)  We need to deal with that as well.  The above three=20=

> mitigate this to a great extent, I think, but to a significant cost..
>
>
> --=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: Mon, 18 Apr 2005 20:28:02 +0000
Date: Mon, 18 Apr 2005 23:27:22 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: flow label demultiplexing

On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
>> Note that HBA+CGA in one doesn't help (AFAICS) because otherwise you'd be 
>> trusting anyone you have a public key with to not hijack any of your 
>> sessions?
>
> Well, i guess not.
>
> In the CGA case, the address being used as the ULID for the communication is 
> a CGA that contains a hash of the publich key in the iid. In this case, you 
> will only trust a public key whose hash matches the iid of the ulid.

Sure.

> So, when you use CGA capabilities of the address, the CGA parameter data 
> structure is exchanged upfront and it contains the public key.
>
> Next, the node can use a new address (that was not included in the CGA 
> parameter data structure) because it can authorize it by signing it with the 
> private key corresponding to the CGA. Moreover, such signature could even be 
> included in a packet that contains the new address as source address (i 
> think)
>
> I mean, with CGA there is no need to know the addresses before hand.

OK, I guess you'll assume that:

  1) the CGA implementations would check the prefix, i.e., that anyone 
who claims to be of prefix A::/64 has a certificate to use that 
prefix, and can present that?   Otherwise you trusting me would allow 
me to say I'm in control of a third party's prefix, right?

  2) delegation path discovery works across the internet so you can 
actually find a common trust anchor, and

  3) you sign the whole [shim6 exchange, and in this case everything, 
if it's piggybacked] packet.  But CGA is only defined for neighbor 
discovery options...

As such, embedding the public key in the CGA/HBA address protects 
against the third parties trying to spoof another person's identity, 
but does not protect against the responder lying.  (This is really bad 
if one would use something like opportunistic encryption rather than 
real "he's my very good friend, he won't try tricks" trust.)  We need 
to deal with that as well.  The above three mitigate this to a great 
extent, I think, but to a significant cost..

-- 
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: Mon, 18 Apr 2005 16:54:50 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Mon, 18 Apr 2005 18:54:35 +0200
To: marcelo bagnulo braun <[email-masked]>

On 18-apr-05, at 18:21, marcelo bagnulo braun wrote:

> So, when you use CGA capabilities of the address, the CGA parameter 
> data structure is exchanged upfront and it contains the public key.

> Next, the node can use a new address (that was not included in the CGA 
> parameter data structure) because it can authorize it by signing it 
> with the private key corresponding to the CGA. Moreover, such 
> signature could even be included in a packet that contains the new 
> address as source address (i think)

But what exactly is signed here? I guess the whole packet, including 
the source address. A man in the middle would be able to modify 
anything that isn't signed. And even then, accepting a packet from an 
unknown source is dangerous because it can lead to a DoS against the 
CPU.

A system where the receiver challenges the sender would be MUCH better 
because that way we have return routability before spending serious CPU 
time.

Delivery-date: Mon, 18 Apr 2005 16:24:18 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Mon, 18 Apr 2005 18:23:53 +0200
To: Pekka Savola <[email-masked]>

On 18-apr-05, at 16:42, Pekka Savola wrote:

>>> This has a couple of generic issues:
>>>  - what if the same flow label is used for some other address, and 
>>> that
>>>    address later gets added to this locator set?

> Host A has locators 2001::1 and 2001::2.  When it establishes 
> communications to B, it uses 2001::1 as source and 2002::B1 as 
> destination locator (and 2002::B2 is backup).  That communication uses 
> flow label = "1".

> Now, Host A (and presumably, also B depending on how it allocates flow 
> labels) marks flow label = 1 as reserved for 
> ({2001::1,2001::2},{2002::B1,2002::B2}).  Normally, the flow label 
> implementation either doesn't do reservation at all or would just mark 
> (2001::1,2002::B1,1) as reserved.

Ok.

> Now, multihoming context is exchanged.

> After that, the host tries to establish a new flow from 2001::1 to 
> 2002::B2; unless there is reservation, it could end up picking "1" as 
> well, which could create issues when either 2002::B1 or 2002::B2 fails 
> because the flow labels overlap.

Hm this isn't how current implementations work. They pick a more or 
less random flow label for each new session. This is encouraged because 
it makes for better hash bucket utilization in boxes that want to do 
something useful with the flow label.

For multihoming, we would probably want to use the same flow label 
instead in order to reuse a previously established context. If having 
all sessions between two hosts use the same flow label is undesirable, 
it may be necessary to tie the multihoming state to ranges of flow 
labels rather than a single one...

> Of course, there is still a race condition between the communication 
> is established and the multihoming context is set up -- there's no way 
> to do the reservation for destination locators before you know which 
> ones they are.

Ok so you're saying a user visits a website at www.ietf.org and the 
html links to an image on images.ietf.org, both have addresses 2001::1 
and 2002::2 and due to DNS load balancing the session to www uses 
2001::1 and the one to images 2002::2. Then, when the sessions are set 
up with the same flow label for each, the shim does its thing and...? 
The sessions will be merged into a single association so there isn't a 
problem, I'd think. Rather the opposite: normal behavior would 99.9999% 
(yes I counted the nines) sure result in two different flow labels but 
now there is one association with two flow labels... But that shouldn't 
be too problematic.

In any event, you wouldn't want to reuse the same flow label any time 
soon irrespective of the addresses.

>> The question is whether we absolutely, positively need to be able to 
>> determine which association a packet belongs to based on addresses 
>> and the flow label, or that it's just a very good guess that may turn 
>> out wrong in later steps. I.e., the machine may have 1000 sessions 
>> open, and being able to narrow down which session a packet belongs to 
>> by looking at the flow label to two or three of those is probably 
>> good enough. If so, then having the source cycle throough the entire 
>> flow label space without even managing collisions with existing 
>> sessions would be enough.

> This is a good point, and I don't recall seeing it in the draft.

> However, I would be interested in hearing if you have ideas what the 
> protocol should do after narrowing the flow label down to 3 or 4.  How 
> does it disambiguate further from those 3 or 4?  Would you rely on the 
> implementation taking a peek at (say) layer 4 headers or some other 
> information?

There are two obvious options:

1. The flow label is relevant regardless of the addresses: this can't 
work because of the possibility of clashes with flow labels in 
unrelated packets
2. The flow label is only relevant with certain source/dest address 
combinations: but what's the additional benefit of the flow label here, 
we can demultiplex on the addresses

I guess the only way the flow label could be useful is as a last resort 
to correlate packets with unknown addresses to existing sessions. But 
this is insecure, so we need to trigger some kind of negotiation to get 
to know the unknown addresses. This could still be somewhat useful 
because if we're 99% sure who we're talking to we can do a one RTT 
challenge/response rather than something more involved.

Or maybe I'm just going down the wrong path here... Why do we need a 
bit in the IP header again?

Delivery-date: Mon, 18 Apr 2005 16:22:03 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Mon, 18 Apr 2005 18:21:29 +0200
To: Pekka Savola <[email-masked]>

El 18/04/2005, a las 16:52, Pekka Savola escribi=F3:

> On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
>>> First, one specific comment:
>>>    An added limitation imposed by this approach is that all the
>>>    potential source and destination locators have to be known=20
>>> beforehand
>>>    by the receiver in order to be recognized.
>>> =3D=3D> I don't understand why this is a limitation in practice =
(though=20
>>> it may be an architectural limitation).  Isn't the assumption that=20=

>>> all the potential locators must be exchanged somehow before the=20
>>> network connectivity failure, otherwise the shim6 solution might not=20=

>>> be able to switch to working locators?  Otherwise the rehoming could=20=

>>> not be secured...
>>
>> Well, if you are using CGA security, you could use the new locator=20
>> (as source address) without prior information to the peer. This could=20=

>> be useful in *some* scenarios (let's not mention the word for now :-)
>> CGA  based security does not need prior exchange of locators, right?
>
> Sorry, I don't quite follow.  Based on my reading of the HBA spec (I=20=

> was more confused when I read the new version, because I had thought=20=

> it worked differently)..

> Is it true that you can use CGA or HBA addresses for connection=20
> survivability only after you have used the shim6 protocol to pass the=20=

> Parameter Data Structure, right?

right. but in the HBA case, the CGA parameter data structure contains=20
the available prefixes, but in the CGA case, it contains the public=20
key, agree?

>   Otherwise I'm not sure how the host could verify the HBA address=20
> (i.e., how is step 1 of Section 5 accomplished otherwise?).
>
> Note that HBA+CGA in one doesn't help (AFAICS) because otherwise you'd=20=

> be trusting anyone you have a public key with to not hijack any of=20
> your sessions?
>

Well, i guess not.

In the CGA case, the address being used as the ULID for the=20
communication is a CGA that contains a hash of the publich key in the=20
iid. In this case, you will only trust a public key whose hash matches=20=

the iid of the ulid.

So, when you use CGA capabilities of the address, the CGA parameter=20
data structure is exchanged upfront and it contains the public key.

Next, the node can use a new address (that was not included in the CGA=20=

parameter data structure) because it can authorize it by signing it=20
with the private key corresponding to the CGA. Moreover, such signature=20=

could even be included in a packet that contains the new address as=20
source address (i think)

I mean, with CGA there is no need to know the addresses before hand.

Make sense?

regards, marcelo

> Or were you talking about the case where the host obtained a new=20
> source locator and wants to start using it immediately, and send the=20=

> first packet using shim6 protocol (also using the new locator as=20
> source),  i.e., "piggybacking"?  That would likely need more than just=20=

> a flow label in any case, so I don't see how that would apply.
>
> --=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: Mon, 18 Apr 2005 14:53:01 +0000
Date: Mon, 18 Apr 2005 17:52:54 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked]
Subject: Re: flow label demultiplexing

On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
>> First, one specific comment:
>> 
>>    An added limitation imposed by this approach is that all the
>>    potential source and destination locators have to be known beforehand
>>    by the receiver in order to be recognized.
>> 
>> ==> I don't understand why this is a limitation in practice (though it may 
>> be an architectural limitation).  Isn't the assumption that all the 
>> potential locators must be exchanged somehow before the network 
>> connectivity failure, otherwise the shim6 solution might not be able to 
>> switch to working locators?  Otherwise the rehoming could not be secured...
>> 
>
> Well, if you are using CGA security, you could use the new locator (as source 
> address) without prior information to the peer. This could be useful in 
> *some* scenarios (let's not mention the word for now :-)
> CGA  based security does not need prior exchange of locators, right?

Sorry, I don't quite follow.  Based on my reading of the HBA spec (I 
was more confused when I read the new version, because I had thought 
it worked differently)..

Is it true that you can use CGA or HBA addresses for connection 
survivability only after you have used the shim6 protocol to pass the 
Parameter Data Structure, right?  Otherwise I'm not sure how the host 
could verify the HBA address (i.e., how is step 1 of Section 5 
accomplished otherwise?).

Note that HBA+CGA in one doesn't help (AFAICS) because otherwise you'd 
be trusting anyone you have a public key with to not hijack any of 
your sessions?

Or were you talking about the case where the host obtained a new 
source locator and wants to start using it immediately, and send the 
first packet using shim6 protocol (also using the new locator as 
source),  i.e., "piggybacking"?  That would likely need more than just 
a flow label in any case, so I don't see how that would 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: Mon, 18 Apr 2005 14:43:24 +0000
Date: Mon, 18 Apr 2005 17:42:52 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: [email-masked]
Subject: Re: flow label demultiplexing

On Mon, 18 Apr 2005, Iljitsch van Beijnum wrote:
>> All the approaches listed in demultiplexing based on flow label appear to 
>> have issues.  It was not clear to me which approaches were really put 
>> forward and which were clearly rejected.
>>
>> When looking at different alternatives, this is what I had in mind which 
>> could work up to a certain degree:
>
>>   1. allocate a new flow label for all new communications immediately
>>   2. when setting up the multihoming context, keep track of all the
>>      potential source and destination locators
>>   3. flow label used by the created (src,dst,flow) in 1. is reserved
>>      so it can't be used for any communication to any destination
>>      locator *in the set*
>>   4. when switching to new locators, use the same flow label
>>   5. when demuxing the packet, the demuxer knows which locators can be used
>>      as source or destination, and use the flow label for demuxing.
>
>> This has a couple of generic issues:
>>  - what if the same flow label is used for some other address, and that
>>    address later gets added to this locator set?
>
> I'm not sure if I understand. Can you give an example?

Brian made a good clarification already, but let me try because the 
bullet point I wrote above is very confusing.

First off, let me try to describe the main idea:

Host A has locators 2001::1 and 2001::2.  When it establishes 
communications to B, it uses 2001::1 as source and 2002::B1 as 
destination locator (and 2002::B2 is backup).  That communication uses 
flow label = "1".

Now, Host A (and presumably, also B depending on how it allocates flow 
labels) marks flow label = 1 as reserved for 
({2001::1,2001::2},{2002::B1,2002::B2}).  Normally, the flow label 
implementation either doesn't do reservation at all or would just mark 
(2001::1,2002::B1,1) as reserved.

Now, multihoming context is exchanged.

After that, the host tries to establish a new flow from 2001::1 to 
2002::B2; unless there is reservation, it could end up picking "1" as 
well, which could create issues when either 2002::B1 or 2002::B2 
fails because the flow labels overlap.

Of course, there is still a race condition between the communication 
is established and the multihoming context is set up -- there's no way 
to do the reservation for destination locators before you know which 
ones they are.

The problem I was referring to above is that caused either by that 
race condition.

> [Note that for our purposes, the destination address is irrelevant as 
> presumably, it can be any of our addresses and we already know who we are. 
> The only thing we care about is source + flow label.]
>
>>    This is better than nothing; the alternative is to do flow
>>    label reservation ("*,*,flow"), but that results in running out of
>>    flow labels with a high number of flows.  Or would that be an
>>    acceptable tradeoff?
>
> The question is whether we absolutely, positively need to be able to 
> determine which association a packet belongs to based on addresses and the 
> flow label, or that it's just a very good guess that may turn out wrong in 
> later steps. I.e., the machine may have 1000 sessions open, and being able to 
> narrow down which session a packet belongs to by looking at the flow label to 
> two or three of those is probably good enough. If so, then having the source 
> cycle throough the entire flow label space without even managing collisions 
> with existing sessions would be enough.

This is a good point, and I don't recall seeing it in the draft.

However, I would be interested in hearing if you have ideas what the 
protocol should do after narrowing the flow label down to 3 or 4.  How 
does it disambiguate further from those 3 or 4?  Would you rely on the 
implementation taking a peek at (say) layer 4 headers or some other 
information?

-- 
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: Mon, 18 Apr 2005 14:28:17 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Mon, 18 Apr 2005 16:27:59 +0200
To: Pekka Savola <[email-masked]>

Hi Pekka,

El 18/04/2005, a las 8:57, Pekka Savola escribi=F3:

> Hi,
>
> Now that the charter bashing has quieted down, some technical=20
> discussion... I've read through the drafts again, and I have some=20
> high-level comments; I'll send a couple of them this week or so.
>
> The first is demultiplexing, especially based on Flow Label.
>
> First, one specific comment:
>
>    An added limitation imposed by this approach is that all the
>    potential source and destination locators have to be known=20
> beforehand
>    by the receiver in order to be recognized.
>
> =3D=3D> I don't understand why this is a limitation in practice =
(though it=20
> may be an architectural limitation).  Isn't the assumption that all=20
> the potential locators must be exchanged somehow before the network=20
> connectivity failure, otherwise the shim6 solution might not be able=20=

> to switch to working locators?  Otherwise the rehoming could not be=20
> secured...
>

Well, if you are using CGA security, you could use the new locator (as=20=

source address) without prior information to the peer. This could be=20
useful in *some* scenarios (let's not mention the word for now :-)
CGA  based security does not need prior exchange of locators, right?

> ....
>
> All the approaches listed in demultiplexing based on flow label appear=20=

> to have issues.  It was not clear to me which approaches were really=20=

> put forward and which were clearly rejected.
>
> When looking at different alternatives, this is what I had in mind=20
> which could work up to a certain degree:
>
>   1. allocate a new flow label for all new communications immediately
>   2. when setting up the multihoming context, keep track of all the
>      potential source and destination locators
>   3. flow label used by the created (src,dst,flow) in 1. is reserved
>      so it can't be used for any communication to any destination
>      locator *in the set*
>   4. when switching to new locators, use the same flow label
>   5. when demuxing the packet, the demuxer knows which locators can be=20=

> used
>      as source or destination, and use the flow label for demuxing.
>
> This has a couple of generic issues:
>  - what if the same flow label is used for some other address, and =
that
>    address later gets added to this locator set?
>
>    This is better than nothing; the alternative is to do flow
>    label reservation ("*,*,flow"), but that results in running out of
>    flow labels with a high number of flows.  Or would that be an
>    acceptable tradeoff?
>
>    If this approach would be used, it would just mean that if you had
>    communicated recently to host X, and host X would soon afterwards =
be
>    added to a locator set, you could not use shim6 to do connection
>    survivability to host X.  This doesn't seem too awful a tradeoff..
>
>  - in step 3. above, an implementation could also perform two-tiered
>    reservation: first reserve the flow label for any communication,
>    but when in the danger of running out, start using it also for
>    those destinations that don't belong to the locator set.  This way
>    this would not be an issue (albeit difficult to debug) until the
>    hosts are so loaded that they're running out of the flow label
>    space for their sessions.
>

IMHO this seems the wise to do it in this approach, i guess.

Regards, marcelo

>  - demultiplexing just using the flow label (and not also source
>    locators) is a non-starter, because then anyone would be able to
>    inject any kind of packet to a particular data stream just by being
>    able to pick the right flow label (and not having to even spoof the
>    source address).  Requiring that the source address is one of the
>    previously communicated locators mitigates this greatly.
>
> --=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: Mon, 18 Apr 2005 11:33:33 +0000
Date: Mon, 18 Apr 2005 13:33:27 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: flow label demultiplexing

Pekka, just one comment on this:

>   1. allocate a new flow label for all new communications immediately 

If you read RFC 3697 closely, you will see that in effect the definition
of a flow is "all packets carrying the same {flow label, srce, dest}".
That is: a flow is whatever set of packets the sending host chooses to
label as a flow. So your statement quoted above is a bit wrong; it
should be

   1. allocate a new flow label at exactly the same time as would be
      done in the absence of shim6.

In fact what you are doing is extending the scope of uniqueness
of a flow label from {srce, dest} to {{srce locators},{dest locators}}.

    Brian

Pekka Savola wrote:
> Hi,
> 
> Now that the charter bashing has quieted down, some technical 
> discussion... I've read through the drafts again, and I have some 
> high-level comments; I'll send a couple of them this week or so.
> 
> The first is demultiplexing, especially based on Flow Label.
> 
> First, one specific comment:
> 
>    An added limitation imposed by this approach is that all the
>    potential source and destination locators have to be known beforehand
>    by the receiver in order to be recognized.
> 
> ==> I don't understand why this is a limitation in practice (though it 
> may be an architectural limitation).  Isn't the assumption that all the 
> potential locators must be exchanged somehow before the network 
> connectivity failure, otherwise the shim6 solution might not be able to 
> switch to working locators?  Otherwise the rehoming could not be secured...
> 
> ....
> 
> All the approaches listed in demultiplexing based on flow label appear 
> to have issues.  It was not clear to me which approaches were really put 
> forward and which were clearly rejected.
> 
> When looking at different alternatives, this is what I had in mind which 
> could work up to a certain degree:
> 
>   1. allocate a new flow label for all new communications immediately
>   2. when setting up the multihoming context, keep track of all the
>      potential source and destination locators
>   3. flow label used by the created (src,dst,flow) in 1. is reserved
>      so it can't be used for any communication to any destination
>      locator *in the set*
>   4. when switching to new locators, use the same flow label
>   5. when demuxing the packet, the demuxer knows which locators can be used
>      as source or destination, and use the flow label for demuxing.
> 
> This has a couple of generic issues:
>  - what if the same flow label is used for some other address, and that
>    address later gets added to this locator set?
> 
>    This is better than nothing; the alternative is to do flow
>    label reservation ("*,*,flow"), but that results in running out of
>    flow labels with a high number of flows.  Or would that be an
>    acceptable tradeoff?
> 
>    If this approach would be used, it would just mean that if you had
>    communicated recently to host X, and host X would soon afterwards be
>    added to a locator set, you could not use shim6 to do connection
>    survivability to host X.  This doesn't seem too awful a tradeoff..
> 
>  - in step 3. above, an implementation could also perform two-tiered
>    reservation: first reserve the flow label for any communication,
>    but when in the danger of running out, start using it also for
>    those destinations that don't belong to the locator set.  This way
>    this would not be an issue (albeit difficult to debug) until the
>    hosts are so loaded that they're running out of the flow label
>    space for their sessions.
> 
>  - demultiplexing just using the flow label (and not also source
>    locators) is a non-starter, because then anyone would be able to
>    inject any kind of packet to a particular data stream just by being
>    able to pick the right flow label (and not having to even spoof the
>    source address).  Requiring that the source address is one of the
>    previously communicated locators mitigates this greatly.
> 

Delivery-date: Mon, 18 Apr 2005 11:32:24 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: flow label demultiplexing
Date: Mon, 18 Apr 2005 13:31:39 +0200
To: Pekka Savola <[email-masked]>

On 18-apr-05, at 8:57, Pekka Savola wrote:

> All the approaches listed in demultiplexing based on flow label appear 
> to have issues.  It was not clear to me which approaches were really 
> put forward and which were clearly rejected.

> When looking at different alternatives, this is what I had in mind 
> which could work up to a certain degree:

>   1. allocate a new flow label for all new communications immediately
>   2. when setting up the multihoming context, keep track of all the
>      potential source and destination locators
>   3. flow label used by the created (src,dst,flow) in 1. is reserved
>      so it can't be used for any communication to any destination
>      locator *in the set*
>   4. when switching to new locators, use the same flow label
>   5. when demuxing the packet, the demuxer knows which locators can be 
> used
>      as source or destination, and use the flow label for demuxing.

> This has a couple of generic issues:
>  - what if the same flow label is used for some other address, and that
>    address later gets added to this locator set?

I'm not sure if I understand. Can you give an example?

[Note that for our purposes, the destination address is irrelevant as 
presumably, it can be any of our addresses and we already know who we 
are. The only thing we care about is source + flow label.]

>    This is better than nothing; the alternative is to do flow
>    label reservation ("*,*,flow"), but that results in running out of
>    flow labels with a high number of flows.  Or would that be an
>    acceptable tradeoff?

The question is whether we absolutely, positively need to be able to 
determine which association a packet belongs to based on addresses and 
the flow label, or that it's just a very good guess that may turn out 
wrong in later steps. I.e., the machine may have 1000 sessions open, 
and being able to narrow down which session a packet belongs to by 
looking at the flow label to two or three of those is probably good 
enough. If so, then having the source cycle throough the entire flow 
label space without even managing collisions with existing sessions 
would be enough.

Delivery-date: Mon, 18 Apr 2005 06:58:05 +0000
Date: Mon, 18 Apr 2005 09:57:26 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: flow label demultiplexing

Hi,

Now that the charter bashing has quieted down, some technical 
discussion... I've read through the drafts again, and I have some 
high-level comments; I'll send a couple of them this week or so.

The first is demultiplexing, especially based on Flow Label.

First, one specific comment:

    An added limitation imposed by this approach is that all the
    potential source and destination locators have to be known beforehand
    by the receiver in order to be recognized.

==> I don't understand why this is a limitation in practice (though it 
may be an architectural limitation).  Isn't the assumption that all 
the potential locators must be exchanged somehow before the network 
connectivity failure, otherwise the shim6 solution might not be able 
to switch to working locators?  Otherwise the rehoming could not be 
secured...

....

All the approaches listed in demultiplexing based on flow label appear 
to have issues.  It was not clear to me which approaches were really 
put forward and which were clearly rejected.

When looking at different alternatives, this is what I had in mind 
which could work up to a certain degree:

   1. allocate a new flow label for all new communications immediately
   2. when setting up the multihoming context, keep track of all the
      potential source and destination locators
   3. flow label used by the created (src,dst,flow) in 1. is reserved
      so it can't be used for any communication to any destination
      locator *in the set*
   4. when switching to new locators, use the same flow label
   5. when demuxing the packet, the demuxer knows which locators can be used
      as source or destination, and use the flow label for demuxing.

This has a couple of generic issues:
  - what if the same flow label is used for some other address, and that
    address later gets added to this locator set?

    This is better than nothing; the alternative is to do flow
    label reservation ("*,*,flow"), but that results in running out of
    flow labels with a high number of flows.  Or would that be an
    acceptable tradeoff?

    If this approach would be used, it would just mean that if you had
    communicated recently to host X, and host X would soon afterwards be
    added to a locator set, you could not use shim6 to do connection
    survivability to host X.  This doesn't seem too awful a tradeoff..

  - in step 3. above, an implementation could also perform two-tiered
    reservation: first reserve the flow label for any communication,
    but when in the danger of running out, start using it also for
    those destinations that don't belong to the locator set.  This way
    this would not be an issue (albeit difficult to debug) until the
    hosts are so loaded that they're running out of the flow label
    space for their sessions.

  - demultiplexing just using the flow label (and not also source
    locators) is a non-starter, because then anyone would be able to
    inject any kind of packet to a particular data stream just by being
    able to pick the right flow label (and not having to even spoof the
    source address).  Requiring that the source address is one of the
    previously communicated locators mitigates this greatly.

-- 
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: Mon, 11 Apr 2005 14:23:49 +0000
Cc: shim6 <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Mon, 11 Apr 2005 10:22:33 -0400
To: Iljitsch van Beijnum <[email-masked]>

On 11 Apr 2005, at 02:36, Iljitsch van Beijnum wrote:

>> <http://www.cisco.com/application/pdf/en/us/guest/tech/tk361/c1550/ 
>> ccmigration_09186a008018221e.pdf>
>
> Read what's in this file more carefully. It's not IPv6-to-IPv6 address  
> translation.

Oh, you're right. My apologies.

Delivery-date: Mon, 11 Apr 2005 06:36:45 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Mon, 11 Apr 2005 08:36:12 +0200
To: Joe Abley <[email-masked]>

On 10-apr-05, at 23:05, Joe Abley wrote:

>> Also, what is this nonsense of "eliminate the use of NATs". There is  
>> no NAT in IPv6 so there is nothing to eliminate.

> I'm not closely following this thread, so don't interpret this as me  
> taking sides, or in fact contributing to the point at hand. However,  
> warning bells are triggered by words such as those on your last  
> sentence, since these things exist,

I don't think so.

> <http://www.cisco.com/application/pdf/en/us/guest/tech/tk361/c1550/ 
> ccmigration_09186a008018221e.pdf>

Read what's in this file more carefully. It's not IPv6-to-IPv6 address  
translation.

Delivery-date: Sun, 10 Apr 2005 21:07:27 +0000
Cc: Dave Crocker <[email-masked]>, shim6 <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Sun, 10 Apr 2005 17:05:50 -0400
To: Iljitsch van Beijnum <[email-masked]>

On 9 Apr 2005, at 09:27, Iljitsch van Beijnum wrote:

> Also, what is this nonsense of "eliminate the use of NATs". There is  
> no NAT in IPv6 so there is nothing to eliminate.

I'm not closely following this thread, so don't interpret this as me  
taking sides, or in fact contributing to the point at hand. However,  
warning bells are triggered by words such as those on your last  
sentence, since these things exist, presumably because people have  
asked for them and plan to deploy them:

<http://www.cisco.com/application/pdf/en/us/guest/tech/tk361/c1550/ 
ccmigration_09186a008018221e.pdf>

Joe

Delivery-date: Sat, 09 Apr 2005 13:29:00 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Open question and Critical dependencies
Date: Sat, 9 Apr 2005 15:27:56 +0200
To: Dave Crocker <[email-masked]>

On 9-apr-05, at 9:26, Dave Crocker wrote:

> But I guess the "IPv6 will take over the world AND will eliminate the 
> use of
> NATs" has become the IETF's version of the OSI wishful-thinking 
> religion.

> Worked great for them.

> No doubt it work even better for us.

So what do you suggest we do? Embrace a "technology" that we know is 
flawed and harmful, leading to more work jusst so we can give people 
more ways to shoot themselves in the foot?

Also, what is this nonsense of "eliminate the use of NATs". There is no 
NAT in IPv6 so there is nothing to eliminate.

It's very easy to bash OSI, but in the mean time the IETF leadership 
thought it was good enough to replace IPv4 more than 10 years ago. And 
we've been more than happy to borrow from them on other occasions: 
AFAIK, the majority of large IP networks run IS-IS.

It's our job as engineers to build good protocols. Whether they're 
adopted isn't up to us, but second guessing ourselves from the start 
and building inferior products just because we're unable to predict the 
future is ridiculous.

Now please, can we get to work?

Delivery-date: Sat, 09 Apr 2005 07:27:07 +0000
From: Dave Crocker <[email-masked]>
To: Thomas Narten <[email-masked]>
CC: shim6 <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 9 Apr 2005 00:26:37 -0700
Subject: Re: Open question and Critical dependencies

Thomas,

It is clear that the main goal of virtually every response to my postings,=
 on 
this thread, is to fend off any serious attention to the questions I am 
raising.  Everything is wonderful and my concerns are either silly or 
excessive.

Still, for some reason, I feel the need of responding to some of your 
comments.  

Maybe my compulsion has something to do with just how important I think the=
 
topic is, and how serious the risks are in the current work plan.  Plus I 
remain impressed that folks are so thoroughly unconcerned about the IETF's 
problematic track record over recent years, largely due to exactly this sort=
 
of failure to plan for easy adoption and early utility.

> >  1. What does "This solution should work whether or not the peer site
> >  supports the shim6 protocol" mean in the draft charter and how can it
> >  succeed?
>
>  I would assume that it means you can't require everyone else to also
>  implement shim6 in order to have working communication. I.e., if a peer
>  doesn't implement shim6, one falls back to standard IPv6, warts and all.

Does it bother anyone that my question generated two, entirely different and=
 
equally plausible explanations of the draft charter text?  Mayhaps the text=
 
needs a bit of clarification?

> >  2. Why is shim6 limited to IPv6?  What is it about the problem space
> >  and/or the solution space that is required to exclude IPv4?
....
>  Another way of looking at it is that if the shim6 work is successful,
>  we'll know a whole lot more about the problem space and the various=
 issues
>  involved in coming up with a solution. At that point, doing an IPv4
>  solution would presumably be a lot easier 

Since the point I raised was a concern about excluding IPv4 from this 
solution, your response confirms that, since 'doing an IPv4 solution" means=
 
"doing a different solution".

> >  3. What happens to shim6 if it must operate through a NAT?
> >
>  This is a good question, but one that I don't think we should get hung=
 up
>  on in terms of a requirement that shim6 work in the presence of NATs.=
 What
>  I think the WG should do is (as it's doing its normal work) is to keep=
 in
>  mind the NAT question and try to avoid breaking NAT as it develops its
>  protocols. 

I did not raise a question about breaking NATs.  I raised a question about 
NATs breaking shim6.

But I guess the "IPv6 will take over the world AND will eliminate the use of=
 
NATs" has become the IETF's version of the OSI wishful-thinking religion.

Worked great for them.  

No doubt it work even better for us.

Can't wait to see how this turns out, after 3-6 years of work.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Delivery-date: Sat, 09 Apr 2005 01:53:01 +0000
Date: Fri, 08 Apr 2005 18:52:18 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Thomas Narten <[email-masked]>, Geoff Huston <[email-masked]>, shim6 <[email-masked]>
Subject: Re: proposed text for charter

marcelo bagnulo braun wrote:

> My understanding is the following:
> 
> Suppose that There are 3 nodes, node A with addresses IPA1, IPA2,..., 
> IPAN, node B with IPB and node c with IPC
> 
> Now node B is communicating with A. As ULIDs for the communication they 
> are using IPB and IPAj.
> 
> so for the communication between A and B if there is a failure in the 
> path associated to IPB and IPAj, the communication can be preserved 
> using alternative locators for node A (assuming both ends support SHIM)
> 
> Now, suppose that the application running on A passes as application 
> level information IPAj to an application running on node C.
> 
> At this point, node C only has one of the addresses associated with node 
> A, IPAj (the one obtained through the referral).
> 
> At this point, if IPAj is unreachable from node C, the communication 
> will fail, because node c has no knowwledge about the alternative 
> locators for node A.
> 
> There are possible solutions for this, like using the reverse tree for 
> obtaining alternative addresses for node A (this may have some problems 
> also) or modifying the app so that all addresses are included in the 
> referral (but this needs changing the app of course)

Modifying the application to use FQDNs in the referral is another 
possibility.

But the above description is correct.

> So, i guess that this is what is being expressed in the charter...

Yes, trying to compress it to fit in a sentence or two in the charter is 
hard.

    Erik

Delivery-date: Thu, 07 Apr 2005 15:28:00 +0000
Cc: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proposed text for charter 
Date: Thu, 7 Apr 2005 17:27:55 +0200
To: Thomas Narten <[email-masked]>

El 07/04/2005, a las 17:11, Thomas Narten escribi=F3:

> Hi  Jari.
>
>>> what does "as long as the IP Address are available" mean? Is this
>>> trying to say anything other than "if packets can still be sent from=20=

>>> A
>>> to B (using whatever addresses happen to work) referrals will also
>>> work"? Or is there some other subtle restriction here?
>>>
>>>
>> Yes. The "addresses are available" part has to do with what
>> has been envisioned as the solution in MULTI6. If you use
>> real IP addresses as your ULIDs then we minimize changes
>> to applications and make it possible to have referrals.
>
>
> What is a "real address"? A globally unique, PA address?
>

good point.

Clearly, a globally unique PA address is a real address.

But it would be good to explore if ULAs can be used for this (as people=20=

have suggested in the past). In this way you could have stable (PI)=20
identifiers. However, in this case, referrals won't work outside of the=20=

routing domain of the particular ula included in the referral. (ther=20
reverse tree thing could work though, if you use unique ulas)

>> However, the drawback of this approach is that if one such address
>> (set) is stored and later retrieved by an application, that address
>> still has to work (or one address from the set) or otherwise you
>> can't continue, because you have no way of asking the peer what his
>> new address is.
>
> I assume that the fundmantal aspect is that the ULID has to be
> mappable into the address used in the (eventual) outer IPv6 header. So
> "real address" must have to do with assumptions about how that mapping
> can be made to work (e.g., one of the addresses in the original set
> can still be used for connectivity with the peer)?

Well, the nice thing about using real addresses is that actually=20
referals would work even if the node that receives the referral does=20
not support the SHIM, right? (with the disclaimer about the=20
reachability of that address)

So, using a real address allows you to not require the mapping service.

for SHIM capable hosts, you could have additional mechanisms to obtain=20=

the rest of the locators, (like contacting the host and using the shim=20=

protocol, the reverse DNS or other)

>
>> (Note that the value of this item in the charter may also not
>> be immediately obvious. Why are we saying that referrals
>> work without application changes? Isn't that a detail?
>
> I don't think this is a detail. Ensuring that referrals work is a key
> aspect of "transparent to higher layers", IMO.
>

agree

regards, marcelo

>> The answer is that this particular choice of requirement
>> happens to dictate to some extent what kind of solution
>> is needed. For instance, if this were not a requirement
>> then identifiers would probably look more like HITs than
>> HBAs/CGAs. Of course the choice of the particular requirement
>> set is a tradeoff -- some NAT/IPv4 things would probably be
>> easier if this were not a requirement.)
>
> Yes, thanks.
>
> Thomas
>

Delivery-date: Thu, 07 Apr 2005 15:21:03 +0000
Cc: Dave Crocker <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Open question and Critical dependencies 
Date: Thu, 7 Apr 2005 17:21:04 +0200
To: Thomas Narten <[email-masked]>

Hi Thomas,

El 07/04/2005, a las 17:00, Thomas Narten escribi=F3:

> Hi Dave.
>
>> The current draft charter prompts some basic questions:
>
> Having now read through this thread...
>
>
>> 1. What does "This solution should work whether or not the peer site
>> supports the shim6 protocol" mean in the draft charter and how can
>> it succeed?
>
> I would assume that it means you can't require everyone else to also
> implement shim6 in order to have working communication. I.e., if a
> peer doesn't implement shim6, one falls back to standard IPv6, warts
> and all.
>

well, the sentence has been taken out of context. the complete=20
paragraph states:

      o Solutions for site exit router selection that works when each =
ISP
        uses ingress filtering, i.e. when the chosen site exit needs to=20=

be
        related to the source address chosen by the host. This solution
        should work whether or not the peer site supports the shim6
        protocol.

In this case is pretty trivial to find a solution that addresses the=20
incompatibility with ingress filtering without upgrading the peer. to=20
mention only one, a solution could be as simple as asking the ISP not=20
to filter anymore packets that have a source address that contains the=20=

alternative prefix assigned to the site. Of course there are more=20
general solutions for this, but they also do not require upgrading the=20=

peer.

i also agree with your comments below.

Regards, marcelo

>
>> 2. Why is shim6 limited to IPv6?  What is it about the problem space
>> and/or the solution space that is required to exclude IPv4?
>
> I think it is pretty obvious that IPv6 has some aspects that IPv4
> doesn't have, and these may make it easier to come up with a solution.
>
> Having said that, I doubt anyone would be so foolish to say if there
> is an approach that happens to work for IPv4 too, we're not allowed to
> use it. :-)
>
> Another way of looking at it is that if the shim6 work is successful,
> we'll know a whole lot more about the problem space and the various
> issues involved in coming up with a solution. At that point, doing an
> IPv4 solution would presumably be a lot easier (read also: won't take
> nearly as long as the shim6 work did), because there is existing work
> to leverage. I think it is perfectly fine to delay working on an IPv4
> approach (if it turns out to be possible/desirable) until a lot more
> of the base work has been done here. At that point, it would make
> sense to re-evaluate whether doing an IPv4 effort still makes sense
> (whether in this WG or a separate one).
>
> I believe that adding some sort of requirement that we also look at
> solving the problem for IPv4 in this WG (at this time) would not
> actually help either effort and is likely to be counterproductive.
>

>> 3. What happens to shim6 if it must operate through a NAT?
>
> This is a good question, but one that I don't think we should get hung
> up on in terms of a requirement that shim6 work in the presence of
> NATs. What I think the WG should do is (as it's doing its normal work)
> is to keep in mind the NAT question and try to avoid breaking NAT as
> it develops its protocols. But requiring that things work through a
> NAT raises the bar significantly, I suspect, in terms of the
> complexity of the solution. I'd prefer making the decision about
> whether NATs can be accomodated when we get to the specific
> engineering tradeoffs of one approach vs. another and see the
> implications of one choice over another.
>
> Adding "works through NATs" as a hard requirement strikes me as
> another potential brick in the "add so many conflicting/hard
> requirements as to make finding a solution impossible".
>

> Thomas
>
>

Delivery-date: Thu, 07 Apr 2005 15:13:47 +0000
Cc: Geoff Huston <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proposed text for charter 
Date: Thu, 7 Apr 2005 17:13:31 +0200
To: Thomas Narten <[email-masked]>

Hi Thomas,

El 07/04/2005, a las 16:36, Thomas Narten escribi=F3:

> Catching up here...
>
> Charter looks good overall, but it is also daunting... there is a
> _lot_ of stuff here....
>
> On one specific point:
>
>> o  ULIDs will be actual IP addresses, permitting existing=20
>> applications to
>>    continue to work unchanged, and permitting application referrals =
to
>>    work, as long as the IP Addresses are available.
>
> I'm not sure I understand what this means.
>
> what does "as long as the IP Address are available" mean? Is this
> trying to say anything other than "if packets can still be sent from A
> to B (using whatever addresses happen to work) referrals will also
> work"? Or is there some other subtle restriction here?
>

My understanding is the following:

Suppose that There are 3 nodes, node A with addresses IPA1, IPA2,...,=20
IPAN, node B with IPB and node c with IPC

Now node B is communicating with A. As ULIDs for the communication they=20=

are using IPB and IPAj.

so for the communication between A and B if there is a failure in the=20
path associated to IPB and IPAj, the communication can be preserved=20
using alternative locators for node A (assuming both ends support SHIM)

Now, suppose that the application running on A passes as application=20
level information IPAj to an application running on node C.

At this point, node C only has one of the addresses associated with=20
node A, IPAj (the one obtained through the referral).

At this point, if IPAj is unreachable from node C, the communication=20
will fail, because node c has no knowwledge about the alternative=20
locators for node A.

There are possible solutions for this, like using the reverse tree for=20=

obtaining alternative addresses for node A (this may have some problems=20=

also) or modifying the app so that all addresses are included in the=20
referral (but this needs changing the app of course)

So, i guess that this is what is being expressed in the charter...

Regards, marcelo

> Thomas
>

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Apr 2005 15:13:34 +0000
Message-Id: <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: proposed text for charter 
Date: Thu, 07 Apr 2005 11:11:54 -0400
From: Thomas Narten <[email-masked]>

Hi  Jari.

> >what does "as long as the IP Address are available" mean? Is this
> >trying to say anything other than "if packets can still be sent from A
> >to B (using whatever addresses happen to work) referrals will also
> >work"? Or is there some other subtle restriction here?
> >  
> >
> Yes. The "addresses are available" part has to do with what
> has been envisioned as the solution in MULTI6. If you use
> real IP addresses as your ULIDs then we minimize changes
> to applications and make it possible to have referrals.

What is a "real address"? A globally unique, PA address?

> However, the drawback of this approach is that if one such address
> (set) is stored and later retrieved by an application, that address
> still has to work (or one address from the set) or otherwise you
> can't continue, because you have no way of asking the peer what his
> new address is.

I assume that the fundmantal aspect is that the ULID has to be
mappable into the address used in the (eventual) outer IPv6 header. So
"real address" must have to do with assumptions about how that mapping
can be made to work (e.g., one of the addresses in the original set
can still be used for connectivity with the peer)?

> (Note that the value of this item in the charter may also not
> be immediately obvious. Why are we saying that referrals
> work without application changes? Isn't that a detail?

I don't think this is a detail. Ensuring that referrals work is a key
aspect of "transparent to higher layers", IMO.

> The answer is that this particular choice of requirement
> happens to dictate to some extent what kind of solution
> is needed. For instance, if this were not a requirement
> then identifiers would probably look more like HITs than
> HBAs/CGAs. Of course the choice of the particular requirement
> set is a tradeoff -- some NAT/IPv4 things would probably be
> easier if this were not a requirement.)

Yes, thanks.

Thomas

Delivery-date: Thu, 07 Apr 2005 15:03:19 +0000
Date: Thu, 07 Apr 2005 18:03:11 +0300
From: Jari Arkko <[email-masked]>
To: Thomas Narten <[email-masked]>
Cc: shim6 <[email-masked]>
Subject: Re: proposed text for charter

Hi Thomas,

>>o  ULIDs will be actual IP addresses, permitting existing applications to
>>   continue to work unchanged, and permitting application referrals to
>>   work, as long as the IP Addresses are available.
>>    
>>
>
>I'm not sure I understand what this means.
>
>what does "as long as the IP Address are available" mean? Is this
>trying to say anything other than "if packets can still be sent from A
>to B (using whatever addresses happen to work) referrals will also
>work"? Or is there some other subtle restriction here?
>  
>
Yes. The "addresses are available" part has to do with what
has been envisioned as the solution in MULTI6. If you use
real IP addresses as your ULIDs then we minimize changes
to applications and make it possible to have referrals. However,
the drawback of this approach is that if one such address (set)
is stored and later retrieved by an application, that address
still has to work (or one address from the set) or otherwise
you can't continue, because you have no way of asking the
peer what his new address is.

(Note that the value of this item in the charter may also not
be immediately obvious. Why are we saying that referrals
work without application changes? Isn't that a detail?
The answer is that this particular choice of requirement
happens to dictate to some extent what kind of solution
is needed. For instance, if this were not a requirement
then identifiers would probably look more like HITs than
HBAs/CGAs. Of course the choice of the particular requirement
set is a tradeoff -- some NAT/IPv4 things would probably be
easier if this were not a requirement.)

--Jari

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Apr 2005 15:02:11 +0000
Message-Id: <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: Open question and Critical dependencies 
Date: Thu, 07 Apr 2005 11:00:19 -0400
From: Thomas Narten <[email-masked]>

Hi Dave.

> The current draft charter prompts some basic questions:

Having now read through this thread...

> 1. What does "This solution should work whether or not the peer site
> supports the shim6 protocol" mean in the draft charter and how can
> it succeed?

I would assume that it means you can't require everyone else to also
implement shim6 in order to have working communication. I.e., if a
peer doesn't implement shim6, one falls back to standard IPv6, warts
and all.

> 2. Why is shim6 limited to IPv6?  What is it about the problem space
> and/or the solution space that is required to exclude IPv4?

I think it is pretty obvious that IPv6 has some aspects that IPv4
doesn't have, and these may make it easier to come up with a solution.

Having said that, I doubt anyone would be so foolish to say if there
is an approach that happens to work for IPv4 too, we're not allowed to
use it. :-)

Another way of looking at it is that if the shim6 work is successful,
we'll know a whole lot more about the problem space and the various
issues involved in coming up with a solution. At that point, doing an
IPv4 solution would presumably be a lot easier (read also: won't take
nearly as long as the shim6 work did), because there is existing work
to leverage. I think it is perfectly fine to delay working on an IPv4
approach (if it turns out to be possible/desirable) until a lot more
of the base work has been done here. At that point, it would make
sense to re-evaluate whether doing an IPv4 effort still makes sense
(whether in this WG or a separate one).

I believe that adding some sort of requirement that we also look at
solving the problem for IPv4 in this WG (at this time) would not
actually help either effort and is likely to be counterproductive.

> 3. What happens to shim6 if it must operate through a NAT?

This is a good question, but one that I don't think we should get hung
up on in terms of a requirement that shim6 work in the presence of
NATs. What I think the WG should do is (as it's doing its normal work)
is to keep in mind the NAT question and try to avoid breaking NAT as
it develops its protocols. But requiring that things work through a
NAT raises the bar significantly, I suspect, in terms of the
complexity of the solution. I'd prefer making the decision about
whether NATs can be accomodated when we get to the specific
engineering tradeoffs of one approach vs. another and see the
implications of one choice over another.

Adding "works through NATs" as a hard requirement strikes me as
another potential brick in the "add so many conflicting/hard
requirements as to make finding a solution impossible".

Thomas

Envelope-to: [email-masked]
Delivery-date: Thu, 07 Apr 2005 14:38:17 +0000
Message-Id: <[email-masked]>
To: Geoff Huston <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: proposed text for charter 
Date: Thu, 07 Apr 2005 10:36:08 -0400
From: Thomas Narten <[email-masked]>

Catching up here...

Charter looks good overall, but it is also daunting... there is a
_lot_ of stuff here....

On one specific point:

> o  ULIDs will be actual IP addresses, permitting existing applications to
>    continue to work unchanged, and permitting application referrals to
>    work, as long as the IP Addresses are available.

I'm not sure I understand what this means.

what does "as long as the IP Address are available" mean? Is this
trying to say anything other than "if packets can still be sent from A
to B (using whatever addresses happen to work) referrals will also
work"? Or is there some other subtle restriction here?

Thomas