|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: v6 subnet size for DSL & leased line customers
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
|