Consensus on MHAP/v6 Multi-homing

[marcelo bagnulo braun]

Hi Jeroen,

El 20/04/2005, a las 12:29, Jeroen Massar escribió:

> 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.
>

agree

>>   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.
>

i fail to see what directory are you talking about here...
I mean AFAIU, shim will use the DNS to obtain addresses, just as it is 
done today, no changes to that, or are you thinking about other 
directory service?

> 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.
>

I fail to understand what are considering here... The changes in the 
locator set of a shim context will be done through the shim protocol 
between the end nodes involved in the communication, right? so, what is 
BGP and overlay come into this?

Regards, marcelo


>> 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
>