Subject: Shim6 Agenda for IETF 71

From: Geoff Huston <[email-masked]>
Date: Sat, 01 Mar 2008 21:14:08 +1100

Hi,

Here's the agenda for the Shim6 meeting at IETF 71 (Monday afternoon 
session 1 (1300 - 1500)

   Geoff

Shim6 Agenda for IETF 71

1. Summary of current WG Document status
     Kurtis Lindqvist

2. ESD
     Erik Nordmark
     draft-nordmark-shim6-esd

3. Proxy Shim6
     Marcelo Bagnulo
     draft-bagnulo-p-shim6

4. Simplifying Proxy Shim6
     Christian Vogt

5. Path Selection
     Olivier Bonaventure
     draft-bonaventure-informed-path-selection-00.txt

6. Next Steps Work Items
     Iljitsch van Beijnum

     A discussion on what's missing from the base specification
     of Shim6 to consider what new work the WG should take on.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Mar 2008 10:29:16 +0100

>    of Shim6 to consider what new work the WG should take on.

Here are some preliminary thoughts on part of this. Please let me know  
what you think so I can grow or shrink this part for next week as  
required...

One of the important things that's still open is the ingress filtering  
situation. The topic of address rewriting in routers in some way also  
resurfaces regularly.

After a discussion with Christian Vogt and some back and forth on the  
IETF list about draft-rosenberg-internet-waist-hourglass-00.txt, I've  
been thinking about NAT in IPv6. The problem with NAT as it's used in  
IPv4 is mainly the port overloading: this breaks incoming traffic.  
Another big problem is the fact that ports and the checksum must be  
rewritten, which means that the NAT must be aware of transport  
protocols. If we get rid of these two issues, NAT almost becomes  
harmless. I'm still not convinced that NAT in IPv6 is a good idea, but  
I AM convinced that if we can limit NAT to strict address translation  
without port overloading that is much, much less harmful than a port  
overloading NAT.

Now combine this with the shim6 proxy, address rewriting and ingress  
filtering stuff and you may end up with something like this:

When an IPv6 host uses unique site locals as source addresses and the  
packets are about to be forwarded to an ISP, the router rewrites the  
top 64 bits of the source address with a prefix that comes from the  
ISP in question. The new top 64 bits of the address are checksum- 
equivalent to the old top 64 bits. (As long as it's /48 prefixes this  
is fairly trivial to do.) This means that ingress filtering is no  
longer an issue. Because the checksums for TCP, UDP, ICMP and DCCP  
remain the same, these protocols don't break. RTP doesn't use a  
checksum (although it's generally used on top of UDP so see UDP) and  
unless I'm mistaken. SCTP doesn't include the addresses in its  
checksum , which is a good thing, because it uses a CRC-32 which I  
don't think is incrementally updatable like the normal checksum.

When packets return, routers don't rewrite the destination address.  
Then, two things can happen: the packets end up at the host itself,  
which recognizes the rewriting and from then on, sources packets with  
the source address that was written in the first packet by the router.  
Or hosts on the subnet are legacy and won't recognize the rewriting,  
so a middlebox rewrites the destination address to the unique site  
local prefix. The host or middlebox can now start shim6 so that if  
there is a path failure, the session/context can move to a different  
address.

For packets that aren't the first in a session and that also aren't  
part of a context for which there is shim6 state, the host (or  
middlebox) would fill in the "real" (external) address as a source  
address, which isn't rewritten by routers. Once shim state is  
negotiated, hosts may return to using the unique site local source  
address which can then be rewritten.

This would be a relatively clean type of NAT, the only thing that it  
breaks is referrals. In IPv4 this is often solved by asking a remote  
host to echo back the external address that it sees, but this would be  
problematic if the site is multihomed so the translation would be to  
different addresses based on which ISP is used to reach a particular  
destination...

In the case of a proxy, it would be nice if the proxy could select the  
full 128 bits of the address so it can create an HBA/CGA address, but  
it probably won't be easy to make this checksum-clean.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2008 12:57:03 +1300

On 2008-03-04 22:29, Iljitsch van Beijnum wrote:

> The new top 64 bits of the address are checksum-equivalent to the old top 64 bits. (As long as it's /48 prefixes this is fairly trivial to do.)

I'm confused. Didn't you just steal all the site's subnet addressing bits?

> This would be a relatively clean type of NAT, the only thing that it breaks is referrals.

Doesn't it also break any upper-layer embedding of IP addresses?
What about MIBs containing addresses, for example?

Also, breaking referrals means we can't escape from today's need to build p2p
systems using some other namespace than IP addresses. That doesn't seem
like what we wanted to achieve.

Back one step:

> Now combine this with the shim6 proxy, address rewriting and ingress filtering stuff and you may end up with something like this: 

I think that a really interesting discussion is whether it's
possible to merge some of the ideas in draft-rja-ilnp-intro-00.txt
with shim6.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Mar 2008 10:03:26 +0100

On 5 mrt 2008, at 0:57, Brian E Carpenter wrote:

>> The new top 64 bits of the address are checksum-equivalent to the  
>> old top 64 bits. (As long as it's /48 prefixes this is fairly  
>> trivial to do.)

> I'm confused. Didn't you just steal all the site's subnet addressing  

I just borrow them.  :-)

For instance, if I use 20:21:22:23 locally and then I get prefix  
10:11:12 from my ISP, then 20+21+22+23 = 10+11+12+X so X =  
20+21+22+23-10-11-12 = 56 so my globally visible subnet is  
10:11:12:56. Then, when a packet returns and is translated back, we do  
the whole business in reverse and 20:21:22:23 reemerges.

> What about MIBs containing addresses, for example?

Wouldn't that be classifyable as "referrals", too? I do agree this  
breaks those. However, in many cases, this can be compensated for by  
the application finding out a global address and embedding that  
address. This is one of the steps in IPv4 NAT traversal and as far as  
I know, certainly not the hardest.

> like what we wanted to achieve.

Well, if it's a choice between this and a scalable internet with  
global addressability and reachability, then I'd choose the latter.  
But if it's a choice between this and a non-scalable internet with  
global addressability (with possible reachability trouble because of  
the non-scaling) and a scalable internet without global addressability  
or reachability because of port overloading NATs, I'd probably choose  
this solution rather than either alternative. I'm not entirely sure  
these are our choices, though.

>> Now combine this with the shim6 proxy, address rewriting and  
>> ingress filtering stuff and you may end up with something like this:

> possible to merge some of the ideas in draft-rja-ilnp-intro-00.txt

Sigh. Can't we just take 8+8/GSE out back and shoot it already?

The RRG should know better than to shoehorn new ideas in existing  
packet formats. That's what we do over at the IETF. What we need is a  
clean loc/id architecture, that shows how locators can easily be  
renumbered because people won't be tempted to put them into their  
firewalls, shows how to get locators from identifiers in a scalable  
way that's fast enough and how the security is done. That's all stuff  
that's missing from 8+8/GSE. Ran's new take on this is a bit better  
than that, but only in an incremental way, fundamentally it's still  
the same tired idea.

---

From: Sébastien Barré <[email-masked]>
Date: Thu, 06 Mar 2008 18:37:06 +0100

Hi,

Iljitsch van Beijnum schreef:
> local prefix. 
This means that it is a requirement to have one of these three options 
(for packet return) :
- All hosts are legacy (and the middlebox always rewrites)
- All hosts recognize the rewriting (and the middlebox never rewrites)
- some hosts are legacy, other not, but the middlebox must be aware of 
the state of each host, so that it can selectively rewrite.

Is it right ?
> The host or middlebox can now start shim6 so that if there is a path 
> failure, the session/context can move to a different address.
Isn't there a possibility that a Shim6 context is established by both 
the middlebox and the host ? Or maybe this can be avoided by 
synchronizing the heuristics for Shim6 negotiation between the host and 
the middlebox  ?

regards,

Sébastien.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 Mar 2008 17:16:57 -0500

> Iljitsch van Beijnum schreef:

Inderdaad!

>> which recognizes the rewriting and from then on, sources packets  
>> with the source address that was written in the first packet by the  
>> router. Or hosts on the subnet are legacy and won't recognize the  
>> rewriting, so a middlebox rewrites the destination address to the  
>> unique site local prefix.

> This means that it is a requirement to have one of these three  
> options (for packet return) :
> - some hosts are legacy, other not, but the middlebox must be aware  
> of the state of each host, so that it can selectively rewrite.

> Is it right ?

Yes, it is. This is a limitation that exists per-subnet. For each  
subnet, you would have to choose one of these options.

>> The host or middlebox can now start shim6 so that if there is a  
>> path failure, the session/context can move to a different address.

> Isn't there a possibility that a Shim6 context is established by  
> both the middlebox and the host ? Or maybe this can be avoided by  
> synchronizing the heuristics for Shim6 negotiation between the host  
> and the middlebox  ?

This is one of the things that must be worked out in a proxy shim6  
scheme. I'd say that a smart middlebox would recognize that a host can  
do shim6 itself and then get out of the way unless it's configured to  
overrule host-based shim6. In that case it could simply filter packets  
with the shim protocol in the protocol chain. The reason a proxy may  
want to do this is that the site administrator desires centralized  
control of traffic engineering decisions.

The next step would be for hosts to be aware of the proxies and work  
together in some way. This is obviously an area for further study...