Consensus on MHAP/v6 Multi-homing

[Jeroen Massar]

On Wed, 2005-04-20 at 11:01 +0100, Cameron Gray wrote:
> OK,
> 
> I'm starting to see MHAP as one giant leap backwards.  It simply appears 
> to be public -> public NAT for multi-homed /48s.

If you s/MHAP/shim6/ (MHAP proposal does not really exist any more) and
indeed that is what it is. Basically a double NAT with public, globally
unique, address space on both sides of the NAT, which takes care of the
problem with the current RFC1918+NAT problem, the biggest of which is
not the NAT it self but the non-uniqueness of the addresses. The double
NAT takes care that apps can still use the public address inside the
protocol, eg as with ftp or h323 and it won't be hurt by the shim.

>   It doesn't help for 
> example with DNS where you want multipath over x providers.

Most likely shim6 will depend on some sort of directory and this
directory will not be able to live easily inside a shim area.

Fun part is that people will most likely want rapid updates for their
shim6-mappings, at a certain point one will then simply have an overlay
BGP network with all the routes in it too. One can drop the ASPATH
partially then though, one only needs it to check for loops.

> Current best practise says only announce /32 to backbones (correct???). 
>   Wouldn't this prove simpler (granted a larger table) to allow up to /48s?

The only reason for 'allowing' upto /48's would be that if these would
be "PI IPv6 blocks" that they at least do not consume that much address
space. For the rest there is not a real reason for a /32 or a /48.

Most ISP's actually allow /48's to come through as can be verified
easily by looking at GRH.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/93741bc9/attachment.bin