Mat,
Exactly. A movable boundary (and its consequence, asking registries to make
judgement calls) is a proven enemy of route aggregation, renumbering,
and multi-homing. The lack of IPv4 addresses forced us into this situation,
as per RFC 2050. As Matt Crawford's calculation proves, there is nothing
forcing us into such a situation with IPv6. It's simple arithmetic.
Just allocate /48s.
Brian
[EMAIL PROTECTED] wrote:
>
> If /56 can be agreed upon as a default then that is not too bad IMO.
> However, the RIRs seem to be veering towards allowing LIRs to allocate
> whatever they choose between /48 and /64 - a movable boundary which will
> scupper the technical objectives of multihoming and simplified
> site-renumbering. I believe the idea of a movable boundary should be
> strongly opposed for this reason.
>
> Regards,
>
> Mat Ford.
>
> -----Original Message-----
> From: Francis Dupont [mailto:[EMAIL PROTECTED]]
> Sent: 07 July 2000 08:22
> To: Brian E Carpenter
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document
> Revision
>
> In your previous mail you wrote:
>
> Can you explain why people think there is any need to allocate anything
> longer than a /48 in the first place?
>
> => many ISPs want to allocate /64 (or worse) to their customers... and
> shout a /48 per customer is far too large. I believe this is a consequence
> of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs,
> ISPs take back the burden to their customers).
> The idea is to introduce a small site (/56) for "poor & little" customers
> and to make it the *default* allocation. IMHO this is an acceptable target.
>
> Regards
>
> [EMAIL PROTECTED]
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
