Re: IPv6 Allocation Policy

"Craig A. Huegen" wrote:
> 
> On Thu, 15 May 2003, Brian E Carpenter wrote:
> 
> > "Craig A. Huegen" wrote:
> > ...
> > > The challenge: how to define a "large multi-national end-user" such that
> > > it would embody the spirit of what we're trying to accomplish.
> >
> > What we're trying to accomplish, presumably, is keeping the size of
> > the default BGP4+ table under control while allowing large multinationals
> > to be connected at many points to multiple ISPs using today's technology.
> >
> > However, I suspect that any attempt to define "large multinational"
> > precisely is going to be hard. It would be a brave person who
> > defines N and M in "has physical sites in at least N countries,
> > and is connected worldwide to at least M different ISPs."
> 
> That's precisely why I was a coward.  However, I'm not sure that N
> countries is a real factor that should be considered; really, I think the
> factors are a) number of segments/subnets, and b) number of ISP's
> contributing a prefix to the end user.
> 
> I think the cleanest solution is finding some way to use the existing
> policy but slightly amended for end-user.  Let me throw what I would
> consider reasonable:  end-user networks with more than, say, 1000 segments
> and 2 discrete ISP's?

I can live with that, but if my employer's network had, say, 999
segments I might be objecting violently :-)

> 
> On top of that, I do have one other concern...  how does an end-user
> network obtain address space that would be routable when divided into the
> separate geographic regions?  For example, if I want address space that I
> can divide into chunks, each announced from a different Internet access
> point, do I need to ask for a /32 for each of the routing points or should
> the RIR's be advising ISP's that they should do filtering, if necessary,
> at minimum_allocation + 4 bits, or something like that?  I realize the
> RIR's don't want to guarantee routability, but they really should take it
> into consideration.

I think that is something we can't fix at the allocation policy level.
Megacorps will do what they do today, until the IETF offers a viable
multihoming solution. And that is being vigorously debated on the
relevant IETF list.

   Briam
_______________________________________________
global-v6 mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/global-v6