Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli <joelja () bogus com>]

Joe Greco wrote:
> > There is a huge detent at /48, but there's a certain amount of guidance
> > that can only be derived from operational experience. It's not clear to
> > me why /56 would be unacceptable, particularly if you're delegating them
> > to a device that already has a /64. Are one's customers attached via
> > point-to-point links, or do they sit on shared broadcast domain where
> > their cpe is receiving a /128 and requesting pd from the outset?
> >
> > When someone plugs an apple airport into a segment of the corporate lan
> > should it be be able to request pd under those circumstances as well?
> > how is that case different than plugging it in on a residential connection?
> >
> > These are issues providers can and should grapple with. 
>
> More likely, at least some of them are fairly naive questions.
>
> For example, /experience/ tells us that corporate LAN policies are often
> implemented without regard to what "we", as Internet engineers, would
> prefer, so I can guarantee you with a 100% certainty that there will be
> at least some networks, and more than likely many networks, where you
> will not be able to simply request a prefix delegation and have that work
> the way you'd like.  There will always be some ISP who has delegated, or
> some end site who has received, a "far too close to being just large
> enough" allocation, and so even if we assume that every router vendor
> and IPv6 implementation from here to eternity has no knobs to disable
> prefix delegation, simple prefix exhaustion within an allocation will be 
> a problem.  All the screams of "but they should have been allocated more"
> will do nothing to change this.
>
> Further, if we consider, for a moment, a world where prefix delegation is
> the only method of adding something like an Apple Airport to an existing
> network, this is potentially encouraging the burning of /64's for the
> addition of a network with perhaps a single client.  That's perfectly fine,
> /as long as/ networks are allocated sufficient resources.  This merely
> means that from a fairly pessimistic viewpoint, IPv6 is actually a 64-bit
> address space for purposes of determining how much address space is
> required.
>
> So, from the point of view of someone manufacturing devices to attach to
> IPv6 networks, I have some options.
>
> I can:
>
> 1) Assume that DHCP PD is going to work, and that the end user will have
>    a prefix to delegate, which might be valid or it might not.  This leaves
>    me in the position of having to figure out a backup strategy, because I
>    do not want users returning my device to Best Buy because "it don't
>    work."  The backup strategy is bridging.
>
> 2) Assume that DHCP PD is not going to work, and make bridging the default
>    strategy.  DHCP PD can optionally be a configurable thing, or autodetect,
>    or whatever, but it will not be mandatory.
>
> I am being facetious here, of course, since only one of those is really
> viable in the market.  Anyone who thinks otherwise is welcome to explain to
> me what's going to happen in the case where there are no P's to D.

It's likely that the device may choose to nat when they cannot obtain a
prefix... pd might be desirable but if you can't then the alternative is
easy.

The current apple airport bridges v6 while natting ivp4 this is a
perceived boundary problem in some circles and likely will be addressed
in future software revision.

> I will leave the difference between corporate and residential as an exercise
> to the reader; suffice it to say that the answers are rather obvious in the
> same manner.
>
> ... JG