who gets a /32 [Re: IPV6 renumbering painless?]

Stephen Sprunk stephen at sprunk.org
Fri Nov 19 20:27:05 UTC 2004


Thus spake "Iljitsch van Beijnum" <iljitsch at muada.com>
> On 19-nov-04, at 5:38, Stephen Sprunk wrote:
>> According to multi6, you will get PA space from each of your ISPs and 
>> overlay a prefix from each on every subnet.  I'll save y'all another rant 
>> on the workability of that model...
>
>> Some fear that you would more likely just generate a ULA, use that 
>> internally, and NAT at the borders.
>
> It isn't contrary to multi6 gospel to have the address swapping be done by 
> boxes somewhere in the middle rather than have all hosts do it for 
> themselves.

Isn't "address swapping ... by boxes somewhere in the middle" called NAT?

> Note that at this time the main focus of the IETF multi6 working group is 
> taking regular communication (such as a TCP session between PA addresses 
> at both ends) and then repair outages using additional PA addresses.

That's interesting, but how long until we see it in Windows (the most 
ubiquitous host OS on the planet)?  It took nearly ten years for MS to 
implement IPv6 as it is; will it take another decade for multi6 to have a 
solution that works and is _deployed_?

> Another way to do this is to use non-routable addresses (such as unique 
> site locals) as the addresses that transport protocols such as TCP and 
> applications see, and start remapping those to/from PA addresses from the 
> start. However, this isn't backward compatible and it's more complex so 
> we're not focussing on this approach at this time. I'm pretty confident 
> that we can add this as an additional option later, though.

I'm confident you could add it, but I'm not confident that (a) it'll end up 
implemented by vendors or (b) it won't have the same disadvantages of NAT.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




More information about the NANOG mailing list