> We can never prevent a site from internally subnetting on any boundary
> it chooses, but we should be very clear about the consequences. At the
> same time we have to be consistent in our discussions with the rir's and
> providers about making sure sites have at least the options of /48 &
> /64, and that attempts to allocate less will result in ugly hacks that
> will be hard for them to maintain.

agree entirely.

> The strongest reason to make this a hard architectural boundary is to
> simplify the dev/test/interoperability of the code for the platform
> vendors. 

I guess I'm arguing that we should make it clear to vendors that
it's *not* reasonable to assume that nobody will ever need to subnet
beyond /64.  

> Sites that accept a /64 are stuck with a single subnet, unless
> they have sufficient technical knowledge to break the architecture

and I'm arguing that the 64 bit boundary should not be a wired-in
part of the architecture (just as in hindsight it turned out to be
a bad idea to make class a/b/c boundaries a part of the v4 architecture)
it's not just for sites -  someday we may be forced to rethink 
allocation strategies in a way that gives sites less than /64.

> If a site receives a /64 from their provider, the simplest approach
> would be to bridge the environment. For those that want a more complex
> topology, they will be better-off to lobby their provider for more
> space. Given track records, this is likely to be possible for a simple
> matter of more money. 

'more money' is not always a simple matter - sometimes the difference
is between being able to operate at all or not. 

> For those who don't want to pay for address space,
> but do want to pay for the cost of local implementations which subnet
> longer than /64, they are free to do so. One might point out this is a
> false economy, but people don't always listen.

and it's not always a false economy.  it depends on the other factors.

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

Reply via email to