Re: v6 subnet size for DSL & leased line customers

> > The primary reasons I see for separate networks on
v6 would include
> > firewall policy (DMZ, separate departmental
networks, etc)...
>
> This is certainly one reason for such things.

Really, in most "small business" networks I've
seen, it's by far the main
one if we want to be honest about it.  The use of multiple
networks to
increase performance, for example, is something you can
design around
differently, and modern hardware supports things like LAG
without having
to get into the realm of unimaginably expensive hardware. 
Even if you do
end up putting a quad port ethernet into a server with v6,
the sizes of
the allocations we're discussing would allow you 64
completely separate
"workgroups" with their own server at the /56
allocation size (64 * 4 = 
256).

> > And I'm having some trouble envisioning a
residential end user that
> > honestly has a need for 256 networks with
sufficiently differently
> > policies.  Or that a firewall device can't
reasonably deal with those
> > policies even on a single network, since you
mainly need to protect
> > devices from external access.
>
> Perhaps this is a lack of imagination.
> 
> Imagine that your ethernet->bluetooth gateway wants
to treat the  
> bluetooth
> and ethernet segments as separate routed segments.

That /is/ a lack of imagination.    Or, at
least, reaching pretty far.
The history of these sorts of devices has been, to date, one
of trying to
keep network configuration simple enough that an average
user can use
them.  That implies a default mode of bridging will be
available.

> Now, imagine that some of your bluetooth connected
devices have reasons
> to have some topology behind them... For example, you
have a master
> appliance control center which connects via Bluetooth
to your network,
> but, uses a different household control bus network to
talk to various
> appliances.  For security reasons, you've decided not
to have your
> kitchen appliances be able to talk to your media
devices (Who wants
> a virus in some downloaded movie to be able to change
the temperature
> in your refrigerator?).

Yes, and?  You're saying there are no access controls at the
gateway
level?  I'm not entirely sure that I care for the idea of
making people
route things at the IP level just so they can protect their
fridge from
their DVD.

> > I keep coming to the conclusion that an end-user
can be made to work  
> > on
> > a /64, even though a /56 is probably a better
choice.  I can't find  
> > the
> > rationale from the end-user's side to allocate a
/48.  I can maybe see
> > it if you want to justify it from the provider's
side, the cost of  
> > dealing
> > with multiple prefix sizes.
>
> I can easily envision the need for more than a /64 in
the average home
> within short order. 

You should probably correct that from "need" to
"want."  There is nothing
preventing the deployment of all of the below on a single
/64, it would
simply mean that there would be a market for smart
firewalling switches
that could isolate devices by address or range, rather than
having smart
firewalling routers that could isolate devices by subnet.

> If nothing else, the average home will probably
> want to be able to accommodate:
> 	Guest network
> 	Home wired network
> 	Wireless network(s)
> 	Bluetooth segment(s)
> 	Media network
> 	Appliance Control netowrk
> 	Lighting Control network
> 	etc.
> 
> However, I agree that in any vision I can come up with
today, the need
> for more than 256 is beyond my current imagination.

Again, I think this comes down to a matter of how
configuration is going
to be handled.  I suspect that we're not going to see a
substantial
increase in sophistication on the part of end users.  I
/believe/ that
this will likely mean that device manufacturers will be
building devices
that don't rely on routing for IPv6, since if I go on down
to my employer's
network and plug in a bluetooth gateway, there's really no
guarantee that
I'm going to be able to get my employer's network to
magically route a
network at my gateway, but it's pretty obvious that my
device can play the
role of a bridge.

If we have significant customer-side routing of IPv6, then
there's going
to need to be some way to manage that.  I guess that's
RIPv6/ng.  

More likely-seeming to me, would be that a provider might be
willing to
provide a CPE device that had 4, 8, or even 16 jacks on it -
a mini-router
with a separate /64 on each port, less "magic" to
be figured out by the end
user.

This leaves the question of how much you want to trust your
ISP's CPE for
firewalling policy ...  among other things.

> I think it makes sense to assign as follows:
>
> /64 for the average current home user.
> /56 for any home user that wants more than one subnet
> /48 for any home user that can show need.

I'd say skip the /64 and /48.  Don't do the /64, as
future-proofing.  A
/48 is just something I cannot see need for, given the
number of addresses
available as a /56, unless the "home user" is
actually providing
connectivity to a bunch of his nearby friends and
neighbors.

Having fewer options is going to be easier for the ISP, I
suspect.

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

On Dec 21, 2007, at 9:39 AM, Joe Greco wrote:

>>> The primary reasons I see for separate networks
on v6 would include
>>> firewall policy (DMZ, separate departmental
networks, etc)...
>>
>> This is certainly one reason for such things.
>
> Really, in most "small business" networks
I've seen, it's by far the  
> main
> one if we want to be honest about it.  The use of
multiple networks to
> increase performance, for example, is something you can
design around
> differently, and modern hardware supports things like
LAG without  
> having
> to get into the realm of unimaginably expensive
hardware.  Even if  
> you do
> end up putting a quad port ethernet into a server with
v6, the sizes  
> of
> the allocations we're discussing would allow you 64
completely  
> separate
> "workgroups" with their own server at the /56
allocation size (64 *  
> 4 =
> 256).
>
Agreed.  In fact, in any network large enough to matter,
most modern
hardware forwards L2 and L3 at the same speed, so, there's
essentially
no performance barrier.

OTOH, in many business netwoks I've seen, there is reason to
segment
things into administrative boundaries, boundaries that
result from media
conversion creating routed separation of segments, and,
other topology
meets physical limitation issues.  I find these to be at
least as common
as the separation between Internal/External/DMZ.

>>> And I'm having some trouble envisioning a
residential end user that
>>> honestly has a need for 256 networks with
sufficiently differently
>>> policies.  Or that a firewall device can't
reasonably deal with  
>>> those
>>> policies even on a single network, since you
mainly need to protect
>>> devices from external access.
>>
>> Perhaps this is a lack of imagination.
>>
>> Imagine that your ethernet->bluetooth gateway
wants to treat the
>> bluetooth
>> and ethernet segments as separate routed segments.
>
> That /is/ a lack of imagination.    Or, at
least, reaching pretty  
> far.
> The history of these sorts of devices has been, to
date, one of  
> trying to
> keep network configuration simple enough that an
average user can use
> them.  That implies a default mode of bridging will be
available.
>
You are ignoring the reality of the difference between IPv4
and IPv6.

With DHCP6 prefix delegation, creating a hierarchical routed
topology
becomes as simple (from the end user perspective) as the
bridged
topology today, and, requires a lot less thinking ability on
the device.
Especially when you consider the possibility of many such
topologies
evolving in a situation that could create a loop and the
fact that most
such existing devices implement bridging without spanning
tree.

>> Now, imagine that some of your bluetooth connected
devices have  
>> reasons
>> to have some topology behind them... For example,
you have a master
>> appliance control center which connects via
Bluetooth to your  
>> network,
>> but, uses a different household control bus network
to talk to  
>> various
>> appliances.  For security reasons, you've decided
not to have your
>> kitchen appliances be able to talk to your media
devices (Who wants
>> a virus in some downloaded movie to be able to
change the temperature
>> in your refrigerator?).
>
> Yes, and?  You're saying there are no access controls
at the gateway
> level?  I'm not entirely sure that I care for the idea
of making  
> people
> route things at the IP level just so they can protect
their fridge  
> from
> their DVD.
>
I'm saying that bridges tend not to have access controls or
at least not
adequate access controls except in a few (l2 firewall
oddities like
Netscreen/PIX in Bridge mode) exceptional cases.  The point
here
is that in IPv6, you aren't "making people route
things", the routing
topology will mostly handle itself automatically, although,
people
may wish to intervene to design the security policy or at
least have
the ability to modify it from the default.

You are trying to apply strictly IPv4 thinking to IPv6, and,
there are
some reasons that a significant paradigm shift is required.

>>> I keep coming to the conclusion that an
end-user can be made to work
>>> on
>>> a /64, even though a /56 is probably a better
choice.  I can't find
>>> the
>>> rationale from the end-user's side to allocate
a /48.  I can maybe  
>>> see
>>> it if you want to justify it from the
provider's side, the cost of
>>> dealing
>>> with multiple prefix sizes.
>>
>> I can easily envision the need for more than a /64
in the average  
>> home
>> within short order.
>
> You should probably correct that from "need"
to "want."  There is  
> nothing
> preventing the deployment of all of the below on a
single /64, it  
> would
> simply mean that there would be a market for smart
firewalling  
> switches
> that could isolate devices by address or range, rather
than having  
> smart
> firewalling routers that could isolate devices by
subnet.
>
We will agree to disagree on this.  Enforcing security
policy within
a subnet is ugly at best and unreliable at worst. It makes 

troubleshooting
harder.  It makes security policy design more complex.  It
causes many
many more problems than it solves in my opinion.

>> If nothing else, the average home will probably
>> want to be able to accommodate:
>> 	Guest network
>> 	Home wired network
>> 	Wireless network(s)
>> 	Bluetooth segment(s)
>> 	Media network
>> 	Appliance Control netowrk
>> 	Lighting Control network
>> 	etc.
>>
>> However, I agree that in any vision I can come up
with today, the  
>> need
>> for more than 256 is beyond my current
imagination.
>
> Again, I think this comes down to a matter of how
configuration is  
> going
> to be handled.  I suspect that we're not going to see a
substantial
> increase in sophistication on the part of end users.  I
/believe/ that
> this will likely mean that device manufacturers will be
building  
> devices
> that don't rely on routing for IPv6, since if I go on
down to my  
> employer's
> network and plug in a bluetooth gateway, there's really
no guarantee  
> that
> I'm going to be able to get my employer's network to
magically route a
> network at my gateway, but it's pretty obvious that my
device can  
> play the
> role of a bridge.
>
Actually, there is some guarantee that, in IPv6, you'll be
able to do  
that,
or, you will know that you could not.  You will make a DHCP6
request
for a prefix delegation, and, you will receive it or be told
no.

Most likely, that is how most such v6 gateways will
function.

I think that bridges are less likely to be the norm in
IPv6.

> If we have significant customer-side routing of IPv6,
then there's  
> going
> to need to be some way to manage that.  I guess that's
RIPv6/ng.  
>
Nope... DHCPv6 prefix delegation and Router discovery.

> More likely-seeming to me, would be that a provider
might be willing  
> to
> provide a CPE device that had 4, 8, or even 16 jacks on
it - a mini- 
> router
> with a separate /64 on each port, less
"magic" to be figured out by  
> the end
> user.
>
Sure.  And likely, the /64s on each port will be assigned
via DHCPv6  
from
the upstream segment.

> This leaves the question of how much you want to trust
your ISP's  
> CPE for
> firewalling policy ...  among other things.
>
LoL... Trust my ISPs CPE?  Not if they control it.

>> I think it makes sense to assign as follows:
>>
>> /64 for the average current home user.
>> /56 for any home user that wants more than one
subnet
>> /48 for any home user that can show need.
>
> I'd say skip the /64 and /48.  Don't do the /64, as
future- 
> proofing.  A
> /48 is just something I cannot see need for, given the
number of  
> addresses
> available as a /56, unless the "home user" is
actually providing
> connectivity to a bunch of his nearby friends and
neighbors.
>
I have no objection to skipping the /64, but, I don't think
you'll get  
much
traction with that with most of the larger ISPs (think AOL,
Comcast,  
etc.)
as I think they will want to charge more for a
topology-supporting  
service
than a single subnet if current business models are an
example of their
plans for the future.

> Having fewer options is going to be easier for the ISP,
I suspect.
>
Nope.  Each ISP can choose to offer whatever subset of these
options  
they consider
easiest.  Having fewer options for them to choose from isn't
easier  
for them, it's putting
them in a straight-jacket, which, from my experience as an
active  
participant in the
ARIN policy process is usually not appreciated by them.

Owen

the "but what if they want the toaster on a separate
subnet from the
blender" gives a new depth to 'reaching.'  the one case
i can think of
for firewalling/routing within the home is to keep the
bathroom scale
from locking the fridge.

and if you can't make a reasonable case for it today, then
yagni.  leave
boiling the ocean to the experts at the tvtf.

randy

Joe Greco wrote:
> I'd say skip the /64 and /48.  Don't do the /64, as
future-proofing.  A
> /48 is just something I cannot see need for, given the
number of addresses
> available as a /56, unless the "home user" is
actually providing
> connectivity to a bunch of his nearby friends and
neighbors.
>
> Having fewer options is going to be easier for the ISP,
I suspect.
>   
Not just the ISP, but the home user, and the designers of
the devices 
for the home. As you point out, device configuration in the
home needs 
to be as simple as possible. It would be nice if designers
of new 
networked home devices (particularly those that that would
like to use 
media types which might not be readily bridged to other
common media 
types) could have some reasonable assurance up front that
they have the 
option of an IPv6 subnet in the home to use. This would then
be one less 
thing to try and automatically discover, ask the user to
configure 
information about, develop a workaround for, etc. Less
options is a very 
good thing here, and rampant /64s could well paint the
device 
manufacturers into a corner on what tools IPv6 gives them to
take 
advantage of.

- Mark
> ... JG
>   

On Dec 22, 2007 1:45 AM, Mark Townsley <townsleycisco.com> wrote:
>
> Joe Greco wrote:
> > I'd say skip the /64 and /48.  Don't do the /64,
as future-proofing.  A
> > /48 is just something I cannot see need for, given
the number of addresses
> > available as a /56, unless the "home
user" is actually providing
> > connectivity to a bunch of his nearby friends and
neighbors.
> >
> > Having fewer options is going to be easier for the
ISP, I suspect.
> >
> Not just the ISP, but the home user, and the designers
of the devices
> for the home. As you point out, device configuration in
the home needs
> to be as simple as possible. It would be nice if
designers of new
> networked home devices (particularly those that that
would like to use
> media types which might not be readily bridged to other
common media
> types) could have some reasonable assurance up front
that they have the
> option of an IPv6 subnet in the home to use. This would
then be one less
> thing to try and automatically discover, ask the user
to configure
> information about, develop a workaround for, etc. Less
options is a very
> good thing here, and rampant /64s could well paint the
device
> manufacturers into a corner on what tools IPv6 gives
them to take
> advantage of.

can you expound some on the last part of this? the 'rampant
/64's..'
part? Since auto-conf pretty much requires the LAN to be /64
sized and
if you believe more than 1 subnet would be of use to the
end-user/residence then there are only a few options left,
eh? It
seems that the ppp-o-e sorts of connections could pass out
this
information and make the lives of equipment/user easier,
what sort of
options were you envisioning? (or what were you hoping to
avoid?)

I ask because I'm fairly certain the operator and
standards-body folks
both would be curious about a vendor's (or
vendor-ish-person's view)
view on this issue, I just don't think a rational answer is
forthcoming from the 'user' community on this quite yet :(

-Chris

Randy Bush wrote:
> the "but what if they want the toaster on a
separate subnet from the
> blender" gives a new depth to 'reaching.'  the one
case i can think of
> for firewalling/routing within the home is to keep the
bathroom scale
> from locking the fridge.
> 
> and if you can't make a reasonable case for it today,
then yagni.  leave
> boiling the ocean to the experts at the tvtf.

If ipv6 subnetting is going to be hosed up at this point
it's going to
be done by people deploying it.

> randy
> 

Joel Jaeggli wrote:
> Randy Bush wrote:
>> the "but what if they want the toaster on a
separate subnet from the
>> blender" gives a new depth to 'reaching.'  the
one case i can think of
>> for firewalling/routing within the home is to keep
the bathroom scale
>> from locking the fridge.
> If ipv6 subnetting is going to be hosed up at this
point it's going to
> be done by people deploying it.

unfortunately, 'hosed up' only seems to be understood some
years out.

smb's point is apt, we always end up too small.

but i still have a very hard time understanding what we are
gonna do
with more than a /56 to a consumer connection.

and if i start to go to the left of a /56, where do i stop? 
there is no
obvious detent on the knob.

randy

Randy Bush wrote:
> Joel Jaeggli wrote:
>> Randy Bush wrote:
>>> the "but what if they want the toaster on
a separate subnet from the
>>> blender" gives a new depth to 'reaching.' 
the one case i can think of
>>> for firewalling/routing within the home is to
keep the bathroom scale
>>> from locking the fridge.
>> If ipv6 subnetting is going to be hosed up at this
point it's going to
>> be done by people deploying it.
> 
> unfortunately, 'hosed up' only seems to be understood
some years out.
> 
> smb's point is apt, we always end up too small.
> 
> but i still have a very hard time understanding what we
are gonna do
> with more than a /56 to a consumer connection.

Leave enough address space for pd to occur? We know that if
I hand you
the end-user a /64 that the first device that you connect to
the network
 (wireless/ethernet router) will nat because it wants a l3
boundary
between the outside and the inside for v6 just like it has
for v4. If
that device, when it boots and requests pd receives a /64,
cool... but
what does it do when some device downstream from it asks for
address space?

So is a /64 ok for an end customer? No because it doesn't
meet the
criterion of a location where one and only one subnet will
be needed.
Does it need a whole /48? Probably not.

What you need in your provisioning system and how you
structure
address-space usage for the benefit of your IGP is that
downstream
devices need to be able to request and receive blocks of a
size
commiserate with their needs without increasing the
footprint of your
routing table.

> and if i start to go to the left of a /56, where do i
stop?  there is no
> obvious detent on the knob.

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. Much
as
assigning a /32 to a residential customer vs /30 or /28 is a
business
decision. In many if not most cases we don't currently
provide as many
v4 addresses as there are devices within the customer
premises. Enough
addresses isn't going to be an issue in v6, The dynamic
creation of
topology that was automatically and at least in one
direction
transparently created by restricted-cone nats is obviously
something new.

> randy
> 

> There is a huge detent at /48

other than the perennial operational pontification from on
high by the
gods of the ietf (brought to us by the folk who brought us
the wonderful
TLA, NLA, etc. classfulness++), could you elucidate?

randy

Randy Bush wrote:
>> There is a huge detent at /48
> 
> other than the perennial operational pontification from
on high by the
> gods of the ietf (brought to us by the folk who brought
us the wonderful
> TLA, NLA, etc. classfulness++), could you elucidate?

>From one angle, last time I looked, the RIRs were
converging on that as
acceptable minimum for a single PI allocation.

/48 is a large enough block that single site however you
choose to
define that, is not going to have to renumber out of it due
to inability
to subnet.

If you mean there's no detent between /48 and /56 wouldn't
you a
wholesale operator determine that based on the need and
guidance from
your rir? We do not in ipv4 land just hand out /19s and /20s
to
customers until we can go back to arin for another /12...

If you're asking why ipng doesn't incorporate the lessons of
cidr
(they're both responses to the same problem), then you tell
me, you were
there and I was in high-schol.

> randy
>