v6 subnet size for DSL & leased line customers

Mailman List Mirror (Read Only)
1

> Why not a /48 for all? IPv6 address space is probably cheap enough that
> even just the time cost of dealing with the occasional justification
> for moving from a /56 to a /48 might be more expensive than just giving
> everybody a /48 from the outset. Then there's the op-ex cost of
> dealing with two end-site prefix lengths - not a big cost, but a
> constant additional cost none the less.

And let's not ignore the on-going cost of table-bloat. If you provide a
/48 to everyone, in 5 years, those allocations may/may not look stupid. :slight_smile:

Right now, we might say "wow, 256 subnets for a single end-user...
hogwash!" and in years to come, "wow, only 256 subnets... what were we
thinking!?"

Well, what's the likelihood of the "only 256 subnets" problem?

Given that a "subnet" in the current model consists of a network that is
capable of swallowing the entire v4 Internet, and still being virtually
empty, it should be clear that *number of devices* will never be a serious
issue for any network, business or residential. You'll always be able to
get as many devices as you'd like connected to the Internet with v6. This
may ignore some /current/ practical issues that devices such as switches
may impose, but that doesn't make it any less true.

The question becomes, under what conditions would you need separate
"subnets". We have to remember that the answer to this question can be,
and probably should be, relatively different than it is under v4. Under
v4, subnet policies involved both network capacity and network number
availability. A small business with a /25 allocation might use a /26 and
a /27 for their office PC's, a /28 for a DMZ, and the last /28 for
miscellaneous stuff like a VPN concentrator, etc. The office PC /26 and
/27 would generally be on different switches, and the server would have
more than one gigE port to accomodate. To deal with higher bandwidth
users, you typically try to split up those users between the two networks.

Under a v6 model, it may be simpler and more convenient to have a single
PC network, with dual gigE LAG (or even 10G) to the switch(es). So I am
envisioning that separate networks primarily imposed due to numbering
reasons under v4 will most likely become single networks under v6.

The primary reasons I see for separate networks on v6 would include
firewall policy (DMZ, separate departmental networks, etc)...

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.

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.

... JG

2

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.

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.

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

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

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.

Owen

3

Once upon a time, Owen DeLong <owen@delong.com> said:

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.

Dumb question alert: why the 8 bit boundary? That makes sense for IPv4,
where reverse DNS delegation is cumbersome on non-octet boundaries, but
IPv6 reverse DNS can be delegated at the nibble boundary. Why not
assign /60, /52, etc.? A /60 would probably satisfy virtually all home
users (up to 16 subnets) for example.

4

Once upon a time, TJ <trejrco@tjevans.net> said:

Short answer - no spec for it.
  ARIN breaks it at /56, as a nod towards maybe a /48 for everyone is
a bit much.

On ARIN's site:

The following guidelines may be useful (but they are only guidelines):

    * /64 when it is known that one and only one subnet is needed
    * /56 for small sites, those expected to need only a few subnets
      over the next 5 years.
    * /48 for larger sites

For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.

So, the guidelines are on 8 bit boundaries, but then right below they
also suggest making assignments on 4 bit boundaries (and it is all "only
guidelines").

5

A /56 is definitely better. Of course, I used to have 4 LANs just in
my house (wired, wireless, VPN to employer, "teen-net" to which certain
users were consigned for violation of the house AUP...). I suspect
there are others on this list with more than that, today.

Sure, we're power users. We're also talking about technology that's
been around for a while. If all of my lights were controlled over the
net, I'd probably want a separate subnet for that, for access control.
I might want a separate subnet for environmental controls, because
access problems there can result in physical damage. I really need to
set up a VPN for remote access to the house.

To quote a line from a science fiction book I'm fond of, "no artificial
shortages!"

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

6

Given that a "subnet" in the current model consists of a network that is
capable of swallowing the entire v4 Internet, and still being virtually
empty, it should be clear that *number of devices* will never be a serious
issue for any network, business or residential. You'll always be able to
get as many devices as you'd like connected to the Internet with v6. This
may ignore some /current/ practical issues that devices such as switches
may impose, but that doesn't make it any less true.

This is the part about V6 I haven't really gotten my head around. It really seems like it takes the position (possibly due to WG-delay) that everything we've learned to do with V4 is done and not-needed.

For example... Within one's own network (or subnet if you will) we can absorb all the concepts of V4 today and have lots of space available. For example... for the DMZ of a business... Why not give them 6 bits (/122?) are we anticipating topology differences UPSTREAM from the customers that can take advantage of subnet differences between /64 and /56 ?

Do we really believe that in our "home" topology where everything has a unique address that my refrigerator won't be able to route to my movie player? And if it can, and if I need a firewall between my in-home networks why does it need to be at /64 boundaries... can I subnet my /64 into a huge number of /116s? I know some IPV6 boxen won't support DHCP and other things at such small network sizes, but I haven't figured out a use for as much space as we are providing even joe-home-user.... or why there is some nobility to making boxes that are less flexible that the IPv4 boxen we have today... between the /48 and /128 boundaries (inclusive)... shouldn't IPv6 be just IPv4 with more space?

My previous understanding was the idea that everyone would get an IP4 universe (or several) to theoretically number everything they could ever conceive of, AND have enough left over to handle things like thousands of interfaces with thousands of simultaneous permanent and semi-permanent conversations going on --even separated by large TTLs (> years) without any concern for numbering/renumbering within their assigned block. I am aware of the idea of renumbering the left portion of the IP space in an IPv6 world...

For example... My car manufacturer could give every car in his universe a unique IP within a network. As an owner of that car, I just need to create a tunnel from my IP space provided by my provider to my car's unique IP (the manufacturer's network won't accept packets for my car NOT from my IP space). So now I can create a webpage from my home that shows all the silly things I do with my car... and its unique and permanent to the rest of the world -- even as I change cars. When I'm "on-the-job" as a physical package courier, my car might even gain another IP with another access model tunneled over to it.

So, I can see a place where LOTS of devices have LOTS of addresses all in different contexts/topologies based on your access model. What I don't understand is why an end user connection today that justifies a /30 needs a /64.. or multiple ones. What at the ISP changes between a /30 and a /56 that we are going to do for that user to support his "multiple random networks of convenience?"

Thanks for any help with my understanding,

DJ

7

Chris Adams <cmadams@hiwaay.net> writes:

Once upon a time, Owen DeLong <owen@delong.com> said:

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.

Dumb question alert: why the 8 bit boundary? That makes sense for IPv4,
where reverse DNS delegation is cumbersome on non-octet boundaries, but
IPv6 reverse DNS can be delegated at the nibble boundary. Why not
assign /60, /52, etc.? A /60 would probably satisfy virtually all home
users (up to 16 subnets) for example.

IPv6 is supposed to last a whole lot longer than the current horizon
for any of our imaginations, and given the large amount of space in
play it seems prudent to err on the side of giving people more rather
than less so as to avoid having to revisit this issue later.

                                        ---rob

8

IPv6 is supposed to last a whole lot longer than the current horizon
for any of our imaginations, and given the large amount of space in
play it seems prudent to err on the side of giving people more rather
than less so as to avoid having to revisit this issue later.

This is more a question of growth rate. If you apply the growth rate "expected" at the inception of IPv4... and compare that to the "expected" growth rate of IPv6... then go extrapolate to calculate "actual"...

well, lets just say 2^128 grows a lot slower than some hockey stick patterns I've seen.

Does IPv4 space become the "swamp" of IPv6 world then?

DJ

9

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

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

<snip>

I think this is also showing a bit of a lack of imagination:

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.

Well, it doesn't really make sense to me - I think it's far more
conservative than it has to be. Even spending time on considering and
evaluating the checkboxes for the last two options is time that could
be better spent on something else, and probably costs more than the
IPv6 address space (and associated costs) saved by being conservative
with the allocations.

I'd be interested to know *why* that makes sense to you - the justifications.

I'd also be interested to know what you'd *want* if you were asked how
you'd like to structure IPv6 addressing, if you didn't have any history
of having to be conservative with IPv4 addressing. IOW, imagine IPv4
didn't exist, and therefore your thinking about IPv6 isn't influenced
by your history with IPv4.

Regards,
Mark.

10

I'd agree that 256 at home seems high to me, today... I do have 10
vlans at home but I could be considered an outlier. I'm not sure that
in the future 10 would even been considered small, maybe things split
on room levels, or appliance types or 'needs vendor support' or some
other set of arbitrary policy points. I agree with you below though
that a /48 seems very large for a residence :slight_smile:

-Chris

11

I am confused on this point as well. IPv6 documents seem to assume
that because auto-discovery on a LAN uses a /64, you always have to
use a /64 global-scope subnet. I don't see any technical issues that
require this though. ICMPv6 is capable of passing info on prefixes of
any length - prefix length is a plain old 8bit field.

In fact, until I read the ARIN documents to receive an assignment at
work, I assumed this would be how people would operate. So what's the
concern? Give all end users a /64 and let them subnet that as they
see fit. If DHCPv6 would take care of it automatically with shorter
prefixes, that's fine - I doubt it cares if it's doling out info for a
/56, /64, or /96. Not like anything on the public internet is going to
care a lick either.

12

Uhm, so sure the spec might be able to do something different than /64
but most equipment I've used only does auto-conf if the prefix is a
/64 :frowning: Somewhere along the path to ipng we got reverted to classful
addressing again :frowning:

-Chris

13

First of all, there's RFC 3513:

For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.

Second, we currently have two mechanisms to configure IPv6 hosts with an address: router advertisements and DHCPv6. The former has been implemented in ALL IPv6 stacks but doesn't work if your subnet isn't a /64. The latter is (I think) available on the client side in Windows Vista. There are a few DHCPv6 server implementations, but the ones I tested 2 years ago wouldn't do address assignment. (You still need the router advertisements to learn your default gateway and prefix length as DHCPv6 can't tell you those.) So although many people want to stick to the DHCP model they know from IPv4, that's extremely hard to do with IPv6 the way things currently are.

14

Not really. Classful IPv4 defined both an addressing structure *and* an
agorithm to match destinations against the route table entries (i.e.
classful forwarding won't match on a default route if the router knows
at least one prefix within a classful network).

IPv6 uses the longest match rule regardless of any addressing
structure, and only uses structure for a few portions of the total
IPv6 address space, for the operation of things like DHCPv6 and address
autoconfiguration. A change in IPv6 addressing structure won't involve
a change in the route table matching algorithm.

Regards,
Mark.

15

Actually we tested DHCv6 implementation 2-3 years ago.
http://www.6net.org/publications/deliverables/D3.2.3v3.pdf

The dibbler seemed to be rather complete DHCPv6 implementation. I think default gateway and prefix length distribution via DHCPv6 will be quite problematical any many situation. There plenty of organisation who has a dedicated team/person for network management (routers, switches etc.), while another team/person for system management (dhcp, servers etc.). So configuring DHCPv6 requires cooperation which takes time, but users are complaining....

Best Regards,
     Janos Mohacsi

16

Mohacsi Janos wrote:

There plenty of organisation who has a dedicated team/person for
network management (routers, switches etc.), while another
team/person for system management (dhcp, servers etc.). So
configuring DHCPv6 requires cooperation which takes time, but users
are complaining....

<well intentioned troll>

so, what problems are there with dhcpv6 that differ from those we have
experienced with dchpv4? what would be good to know before trying to
deploy it?

do organizations you know prefer autoconf or dhcpv6? and why?

randy

17

First of all, there's RFC 3513:

For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.

Ahhh, thanks - that is the only thing I have ever seen that gives any
reason for the /64 prefix. Sadly, the document contains no
compelling technical reasons for it - looks like it's done just so
things are easy when generating interface IDs from ethernet addresses.

Second, we currently have two mechanisms to configure IPv6 hosts with
an address: router advertisements and DHCPv6. The former has been
implemented in ALL IPv6 stacks but doesn't work if your subnet isn't
a /64.

But the protocols don't imply or require this. All of the messages
used in stateless autoconfig will behave as expected with longer prefix
lengths. So it seems that because the interface identifier has to be
64-bits, stateless autoconfig is unnecessarily crippled.

For kicks I just tried RAs with a /96 prefix. Linux 2.6 checks and
enforces the requirement from RFC3513, though it'd be trivial to
change. But I'm guessing other vendors enforce this as well.

18

* Joe Greco:

Right now, we might say "wow, 256 subnets for a single end-user...
hogwash!" and in years to come, "wow, only 256 subnets... what were we
thinking!?"

Well, what's the likelihood of the "only 256 subnets" problem?

There's a tendency to move away from (simulated) shared media networks.
"One host per subnet" might become the norm.

19

Ross Vandegrift <ross@kallisti.us> writes:

Ahhh, thanks - that is the only thing I have ever seen that gives any
reason for the /64 prefix. Sadly, the document contains no
compelling technical reasons for it - looks like it's done just so
things are easy when generating interface IDs from ethernet addresses.

    One good guess for the rationale is to preserve the possibility of
splitting the host and network identifier namespaces, like XNS and
some others do. Should it be deemed the way forward, the current
policy makes it slightly more of a possibility to decouple them after
the fact.

20

Once upon a time, Florian Weimer <fw@deneb.enyo.de> said:

>> Right now, we might say "wow, 256 subnets for a single end-user...
>> hogwash!" and in years to come, "wow, only 256 subnets... what were we
>> thinking!?"
>
> Well, what's the likelihood of the "only 256 subnets" problem?

There's a tendency to move away from (simulated) shared media networks.
"One host per subnet" might become the norm.

So each host will end up with a /64?

How exactly are end-users expected to manage this? Having a subnet for
the kitchen appliances and a subnet for the home theater, both of which
can talk to the subnet for the home computer(s), but not to each other,
will be far beyond the abilities of the average home user.