Subject: Re: Draft: PI addressing derived from AS numbers

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 26 Feb 2003 07:28:09 -0500

> From: Kurt Erik Lindqvist <[email-masked]>

    > I am still curious as to why people think that 16+16 would be any
    > different to 8+8.

To make 8+8 work you have to change the TCP checksum algorithm - or at least
change TCP so that when the locator part of the address changes, it changes
what's in the pseudo-header it uses for computing checksums (and then you
have to make sure you change the pseudo-header at the exact right packet).

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Feb 2003 20:28:30 +0100 (CET)

> have to make sure you change the pseudo-header at the exact right packet).

That's the easy part.

And if you implement 16+16 you get 8+8 almost for free if you make the
last 8 bytes of the first "16" and the first 8 bytes of the last "16" 0.
This will checksum correctly because the presence of additional 0x0000
values in the data to be checksummed doesn't change the result.

The advantage of 16+16 is that you don't have to change hosts: the
checksum and autoconfig still work. Also, if you don't implement 16+16
as two sets of addresses in each packet, but rather as rewriting the
addresses, the necessary state automatically protects you against simple
attacks.

And 16+16 allows large parts of end-user networks to use "topology
independent" addresses (yes, I think that's the right term here, but
"provider independent" will do too). The really cool part there is that
if we decide we're going to do 16+16 we can allow the TI/PI addresses in
the global routing table in the mean time and make them disappear behind
the rewriting boxes when the time comes.

The hard part is setting up the rewriting state. Michel Py has a draft
that basically floods this information over special purpose boxes
throughout the net. I'm more in favor of a system where this information
is negotiated as needed.

Iljitsch