v6 subnet size for DSL & leased line customers
joelja at bogus.com
Mon Dec 24 06:09:55 UTC 2007
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
> 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
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
More information about the NANOG