Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Jan 2007 16:43:20 -0500 (EST)

> From: Tony Li <[email-masked]>

    >> because of TCP checksum issues; the border router can only do so much,
    >> unless the host is in on it too. (Which is why GSE proposed to make
    >> the TCP checksum cover only the ID half, but that horse is long-gone,
    >> alas...)

    > I sincerely hope that we can rein in that horse and reconsider it.
    > Otherwise the entire concept of a host/locator split ends up looking
    > wholly like NAT, either in the host or in the middle box.

Tony (et al), would it be possible to do something where the host emits the
packet with the high halves (the routing-goop) of the IPv6 addresses all
zero, and then the border router fills them in for while the packet is in
transit, and then the last-hop router (or perhaps the border router at the
destination) clears them? That way, the TCP checksum wouldn't have to be
modified (either in the code, or in packets in flight), and the hosts
wouldn't have to be in on the act.

(Yes, I know there's still a security issue with the binding of the RG part
to the endpoint-indentity part; I'm leaving off thinking about that until I
make sure the first step works.)

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Tony Li <[email-masked]>
Date: Mon, 1 Jan 2007 15:11:03 -0800

Noel,

>refore support substrate, like
> identity/location separation), but make the engineering mechanisms  
> different
> in the two cases, to take into account scale differences?

I could be convinced by concrete counter examples, but the only  
distinctions that I can see are:

a) sites that have exactly one ASBR
b) sites that have more than one ASBR

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 1 Jan 2007 15:11:03 -0800

Noel,

> wouldn't have to be in on the act.

In principle, yes I think that something like that is possible.  I  
think that there are some significant details that we would have to  
get into regarding where you draw the routing goop line, and how much  
of the routing goop the host has to see.  I think that there needs to  
be some "local" routing goop within a routing domain so that you can  
scale your IGP.  If that overlaps with the "global" routing goop,  
then I think that the finesse that you're proposing will fail.  I  
also think you'll probably want different constants in the routing  
goop for "external" and "internal", and possibly other routing goop  
bits to select your ASBR.

These of course are dirty little details that need to be ironed out.   
It is because of them that I'm in favor of restricting the header  
checksum rather than just forcing the RG to a constant.  But that's  
just me, trying to do something 'cleaner'.

Tony

> wouldn't have to be in on the act.

In principle, yes I think that something like that is possible.  I  
think that there are some significant details that we would have to  
get into regarding where you draw the routing goop line, and how much  
of the routing goop the host has to see.  I think that there needs to  
be some "local" routing goop within a routing domain so that you can  
scale your IGP.  If that overlaps with the "global" routing goop,  
then I think that the finesse that you're proposing will fail.  I  
also think you'll probably want different constants in the routing  
goop for "external" and "internal", and possibly other routing goop  
bits to select your ASBR.

These of course are dirty little details that need to be ironed out.   
It is because of them that I'm in favor of restricting the header  
checksum rather than just forcing the RG to a constant.  But that's  
just me, trying to do something 'cleaner'.

Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 2 Jan 2007 08:25:07 -0500

Noel, I agree with Tony.  As example if the routing-namespace-identifier
was used in for transport layer then the low order EUI of v6 could be
used for transport protocols. For ICMPv6 same could be done.  Note v6
don't do checksum enroute to the end-node, and only at transport and
icmp.  If we moved to new transport identifiers that did not use
locators (routing-namespace-identifiers) then the point becomes moot for
transport, except for icmp.

Noting in my response your caveat to not worry about e2e dst SPI
example. Or if we did more to this model then do we need a new checksum
in the new layer at some point in the path but not at the end node.

Uggh need to think about packet e2e fragmentation reassembly at some
point too :--).

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Monday, January 01, 2007 4:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering
> 
> Tony (et al), would it be possible to do something where the 
> host emits the packet with the high halves (the routing-goop) 
> of the IPv6 addresses all zero, and then the border router 
> fills them in for while the packet is in transit, and then 
> the last-hop router (or perhaps the border router at the
> destination) clears them? That way, the TCP checksum wouldn't 
> have to be modified (either in the code, or in packets in 
> flight), and the hosts wouldn't have to be in on the act.
> 
> (Yes, I know there's still a security issue with the binding 
> of the RG part to the endpoint-indentity part; I'm leaving 
> off thinking about that until I make sure the first step works.)
> 
> 	Noel
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:40:05 +0100

> wouldn't have to be in on the act.

well, my personal preference would be not to leave the prefix to zero, 
because if we do that, this means that the identifier is the lower 64 
bits and we need to create the means to provide global uniqueness to 
the 64 iid name space.
I think it would be much easier to go for 128 bits identifiers, 
reserving a /8 global prefix for the identifier name space (something 
like the globally managed ULAs, but maybe with some differences on the 
cost structure)
Then these would be local addresses, that the host will use to generate 
packet and these are valid in the local domain. when the packet reaches 
the border of the local domain, the border router rewrites the source 
and/or destiantion prefix with a globally routable prefix and routes it 
through the internet. When the packet reaches the destiantion domain, 
the border router of the destination domain rewrites the prefixes of 
the destiantion and/or the source address, restoring the identifiers to 
the packet.

Of course, in order to do this, state about the mapping between the 
identifiers and the locators must be securely placed in the border 
routers

bottom line: i would go for 128 bit long identifiers (rather than 64 
bit long identifiers) because we already have the means to provide 
global uniqqueness for 128 bit long strings and maybe some other 
reasons that i am forgetting right now...

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 2 Jan 2007 20:44:32 +0200

> well, my personal preference would be not to leave the prefix to  
> zero, because if we do that, this means that the identifier is the  
> lower 64 bits and we need to create the means to provide global  
> uniqueness to the 64 iid name space.
>
> reserving a /8 global prefix for the identifier name space  
> (something like the globally managed ULAs, but maybe with some  
> differences on the cost structure)

For the record, draft-laganier-ipv6-khi-05.txt originally proposed  
such a space.  However, the originally proposed /8 was changed to a / 
28, for a number of reasons.  Reading the int-area archives for the  
argumentation is instructive; as you know some of that was repeated  
in architecture-discuss.

> Then these would be local addresses, that the host will use to  
> generate packet and these are valid in the local domain. when the  
> packet reaches the border of the local domain, the border router  
> rewrites the source and/or destiantion prefix with a globally  
> routable prefix and routes it through the internet. When the packet  
> reaches the destiantion domain, the border router of the  
> destination domain rewrites the prefixes of the destiantion and/or  
> the source address, restoring the identifiers to the packet.

As I wrote at the architecture-discuss list, in those solutions that  
are based on rewriting identifiers to locators and vice versa, there  
are two "architectural" dimensions:

1. Where the rewriting is done logically: "above" transport,  
somewhere within transport and/or host part of IP, or "below" the  
host part of IP, i.e., as a part of the "routing" system.

2. Where the rewriting is done physically: in an application, at the  
host (in a library, stack, or close to the device driver), or in the  
network

Those two dimensions are pretty independent, though not absolutely  
orthogonal.  For example, even if the architectural solution would be  
based on rewriting at the host (like in HIP and SHIM6, among others),  
the rewriting can be implemented in a separate box.  Likewise, even  
if the rewriting was logically done below the host part of IP, as a  
part of the routing system, hosts could still implement it "close to  
the device driver".

I'm writing a draft outlining how to do that, what are the security  
implications, and what are the basic details in each of the nine  
different cases.  However, don't hold your breath; I've also got  
other things to do.  Though, the main message is that these two  
dimensions are pretty independent, and can be varied from site to  
site, depending on operational demands.

--Pekka Nikander

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Jan 2007 13:27:10 -0800

On Jan 2, 2007, at 8:40 AM, marcelo bagnulo braun wrote:

> if we do that, this means that the identifier is the lower 64 bits  
> and we need to create the means to provide global uniqueness to the  
> 64 iid name space.

If you want a field that is semantically an 'identifier', it needs to  
be unique.  Or at the very least statistically unique.

> routable prefix and routes it through the internet.

This would be NAT.  If we're doing NAT, why not just stay with IPv4?

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 02:43:14 +0100

El 02/01/2007, a las 22:27, Tony Li escribió:

>> like the globally managed ULAs, but maybe with some differences on 
>> the cost structure)

no, NAT would be much more simple, attractive and easier to deploy and 
adopt

This would be a double nat, one when we leave the source site and the 
reverse operation when the packet reaches the destiantion site.
The result is that from the endpoint perspective, the packet is 
received exactly the same as it was generated from the source. So apps 
can include address information in the payload and this will be  
coherent with what is actually included in the IP header, Actually it 
would be exactly like a compressed tunnel, just that actual local 
addresses are not included in the actual packet (note that i mean local 
addresses because they are locally routable but globally unique)

So, no, it is not like nat because it lacks of the great deployment 
incentive where the one that has to deploy stuff is the one that gets 
the benefits. In this case both ends need to deploy stuff and only one 
ends gets the benefits (but this is needed in order to get the e2e 
transparency)

Regards, marcelo