Consensus on MHAP/v6 Multi-homing

[Jeroen Massar]

On Wed, 2005-04-20 at 14:39 +0100, Cameron Gray wrote:
> Daniel Austin wrote:
>   > Bear in mind that each /32 is potentially 65536 /48 prefixes if allowed
> > to send all their /48's.  People struggle enough already with only 
> > ~156000 prefixes in ipv4 land.

 32bits * 156.000 = 4 992 000
128bits *  65.000 = 8 320 000 (not assuming private ASN's etc)

At least when you count the bits. Ask the routing vendors if they like
it or not ;)

Biggest question: what do you say to ASN applicant ~70.000 ?

> Agreed, but (in my mind, usual disclaimer) aggregation in IPv6 is far 
> easier?!!!!
> 
> Unlike now where 20% (at my last look, again disclaimer) of the prefixes 
> could be aggregated. Even with "PI" recipients it should only add 1 to 
> the table, not all the /64s (analoguous to ISPx announcing all the /24s 
> in a /19).

Remember that the RIR's gave those organizations the blocks sized
per /19 and they still announce it per /24. Guess oh guess why and guess
what happens.

> > An idea might be to have a specific /32 prefix that the RIR's can 
> > allocate/assign "PI" space from.  Whether or not they will do this and 
> > reasons for/against it is most likely covered by another mailing list.
> 
> Agreed, except they (well RIPE certainly) have stated there will be no 
> PI space.  Even LIRs that cannot plan to issue 200 /64s have to get 
> space from a LIR that can.

200 /48's. Also "RIPE" is the people and as RIPE NCC doesn't make the
rules for RIPE, what you say here is impossible.

If the RIPE membership (not the NCC who actually almost have no 'vote')
make a proposal and this proposal gets accepted by the RIPE membership
then this is what RIPE is going to do because their membership tells
them. Apparently there are either too many ISP's who want to keep the
ropes in their hands (which is what every big ISP wants to because they
need revenue) or there are not enough people who want IPv6-PI.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/ba5d78be/attachment.sig>