Re: The argument for writing a general purpose NAT for IPv6

[Remi Denis-Courmont <rdenis@simphalempin.com>]

On Thu, 26 Apr 2007 17:34:37 -0700, james woodyatt <jhw@apple.com> wrote:

> At this point, I'm now persuaded that having a proxy remote from the

> filtering router will require the path between them to use some kind

> of encapsulation that looks like a routing extension header.



If you transmit "raw" IPv6 packets, yes. Of course, you're going to have

some big headaches with MTU if you encapsulate, however...



Unless you put some logic in the "filtering router" so that it returns

a Packet too big error if it sees a packet it wants to encapsulate but

cannot.



I am personnaly not convinced whether we really need a new RH type instead

of using plain proto-41 encapsulation, though. Another option, that might

not suffer from the MTU issue would be to use a different EtherType and

pass network-layer packets unmodified, but that's ugly and assumes a

shared medium between the filter and the proxy.



> I'm still convinced that type code zero is the *wrong* one, but

> whatever... (at the diversion point, on the return path from the

> proxy, the source address needs to be rewritten to match the real

> destination, not the proxy, and normal routing extension header

> processing doesn't do that.)



I agree. I would additionnaly rather not RHT0 be modified by middleboxes

in a way that is not specified.



--

Rémi Denis-Courmont

http://www.remlab.net/