Consensus on MHAP/v6 Multi-homing

Jeroen Massar jeroen at unfix.org
Wed Apr 20 12:58:38 CEST 2005


On Wed, 2005-04-20 at 11:41 +0100, Cameron Gray wrote:
> Jeroen Massar wrote:
> > 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.
> 
> OK, I wasn't looking at specific application compatibility yet, simply 
> loosing the Multi-Path benefits we have with the current IPv4 consensus.

"Multi-Path benefits" ? You have multiple paths to your destination:

Just in case some wonder what shim6 is supposed to do:
8<------------------------------
shim6 idea
~~~~~~~~~~

Original: 2001:db8::1 -> 3ffe:ffff::1
[ shim6 translates it ]
On wire : 2002:a0a:a0a::1 -> 3ffe:ffff::1

Packet arrives at target as: 2002:a0a:a0a::1 -> 3ffe:ffff::1
But this box knows it is shim6 (extra header or whatever)
and translates it back:
[ shim6 translates it (back) ]
Received: 2001:db8::1 -> 3ffe:ffff::1

Thus the packet is 100% the same as when it was sent, does not matter if there are
IP's embedded etc...
------------------------------>8

The border router can also pick any of the other 'on the wire source
IP's', or in case of shim6, every other /48.

Basically, while on the wire you swap out the first /48 bits to the ones
of your upstream and that is it. For outgoing packets this is merely
done to allow the upstream to do source address filtering as they are
supposed to be doing.

> > 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.
> 
> Sorry, I don't follow the overlay part... SHIM6 with a directory would 
> cause a lookup dictating where each "real" address should be pointed 
> now, but as you say updates to this must be instant and automatic.
> 
> Who gets to run these, ICANN? RIPE/ARIN/APNIC/AFNIC, et al.?  The ISPs 
> I'm worried about won't accept that kind of encroachment onto their 
> routing policy.  The What-Ifs are pretty much endless if they are not in 
> control of that critical part of the new infrastructure.

What do any of those organizations have to do currently with BGP?

The RIR's give out address space, they do not impose any routing
restrictions. Filter is done by ISP's/transits etc, not by the RIR's.

> I would see that the border for ASx would have to network xxxx::xxxx/48 
> both ranges, but only one would be accepted?!?

No, why should it? The 'globally unique address space' is behind the
borders of the multihomed network and as such the /48 is not globally
routed at all, though you can always leak it to friendly people.

> > 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.
> 
> Example; I'm working with a small-mid sized hosting provider; not large 
> enough to even contemplate becoming an LIR for a /32 v6 assignment and 
> definately not going to issue 200 /48s in 2 years.
> 
> We've had UK6X deny announcement to the backbone as its longer than a 
> /32.

Give them more money to announce it. But since when did IX's become
transits? Or did they made a mistake when naming their organization?

>   As far as they are concerned either a) they must get a /32 and 
> flaunt RIPE NCC policies

If they are an ISP and providing address space to you and have a plan
for 200 others then this is not an issue at all with current policies.

>  or b) be allowed to multi home on the /48 they 
> can get from one upstream.  If neither of these options prove fruitful 
> they will simply ignore IPv6 because it's a step backwards.

UK6X is afaik an IX, not an ISP.

> If PI for IPv6 cannot be replicated takeup will be majorly hampered in 
> my opinion as many smaller ISPs will lose what they consider their 
> multihoming option.

Fun question I always have: how many seperate&redundant physical paths
do those 'multihomed' organizations have?

The only real reason for having your own /48, which IMHO is quite valid
is having it because of renumbering hassle as that is the real pain.

Btw isn't address policy discussion supposed to be going on on the RIPE
address-wg and ARIN ppml lists? :)

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/46b1ec9d/attachment.bin


More information about the ipv6-ops mailing list