Re: v6 subnet size for DSL & leased line customers

> 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.

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
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me
one chance [and] then I
won't contact you again." - Direct Marketing Ass'n
position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way
too many apples.

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