[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Re: Six/One Router revised 2008-07-12 - IPsec



Robin -

   MSB                                 LSB

   xxxx xxxx xxxx yyyy zzzz zzzz zzzz zzzz

z bits are unaffected by address translation.

My understanding is that you want to rewrite all of x and y bits, but
you think that in order to keep the checksum the same.  So the best
approach is to rewrite the most important (most significant) bits the
way you want, and not try to be specific about the yyyy 16 bits,
because you are going to have to set them to some value based on the
other changes (difference between the 16 bit sum of the original xxxx
xxxx xxxx bits and the 16 bit sum of their translated values) to keep
the 16 bit checksum from changing.

This therefore would limit the use of your system to prefixes of /48
or shorter - which is not much of a problem, I think.


No, not at all.  You can continue to use the y-bits in the address as
usual.  (These bits are called "subnet ID" in RFC 4291 terminology.)

The subnet ID simply changes by a constant offset as a packet
traverses a Six/One router.  (And FWIW, this constant is the same for
all packets that a given Six/One router forwards.)  The reason why the
subnet ID doesn't lose its meaning is that it is used only within an
edge network, and packets always have the original (unchanged) subnet
ID while within a given edge network.

Of course, the proposed method is just one example of how checksum
changes could be avoided.  Others are possible -- like re-computing
the checksum, or obtaining transit routing prefixes that are
checksum-equivalent with the corresponding edge routing prefix.  (A
"routing prefix" is what RFC 4291 calls the x-bits in the address.)
Since the method is transparent to the remote peer, a Six/One router
can do whatever it likes as long as the checksum in the indirected
packet is consistent with the packet.

And worthwhile to emphasize, you only need any of these methods for
backwards compatibility, not for packet exchanges between upgraded
edge networks.

Does this makes things clearer?

Cheers,
- Christian



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg