nanog mailing list archives
Re: v6 subnet size for DSL & leased line customers
From: Owen DeLong <owen () delong com>
Date: Fri, 21 Dec 2007 09:53:28 -0800
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 mainone if we want to be honest about it. The use of multiple networks to increase performance, for example, is something you can design arounddifferently, 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 differentlypolicies. Or that a firewall device can't reasonably deal with thosepolicies 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 tokeep 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 reasonsto have some topology behind them... For example, you have a masterappliance control center which connects via Bluetooth to your network, but, uses a different household control bus network to talk to variousappliances. 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 gatewaylevel? 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 fromtheir 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 therationale from the end-user's side to allocate a /48. I can maybe seeit 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 homewithin 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 smartfirewalling routers that could isolate devices by subnet.
We will agree to disagree on this. Enforcing security policy withina 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.
Actually, there is some guarantee that, in IPv6, you'll be able to do that,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 needfor more than 256 is beyond my current imagination.Again, I think this comes down to a matter of how configuration is goingto be handled. I suspect that we're not going to see a substantial increase in sophistication on the part of end users. I /believe/ thatthis 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 thatI'm going to be able to get my employer's network to magically route anetwork at my gateway, but it's pretty obvious that my device can play therole of a bridge.
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 goingto 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 endSure. And likely, the /64s on each port will be assigned via DHCPv6 fromuser.
the upstream segment.
This leaves the question of how much you want to trust your ISP's CPE forfirewalling policy ... among other things.
LoL... Trust my ISPs CPE? Not if they control it.
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 serviceI 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 addressesavailable as a /56, unless the "home user" is actually providing connectivity to a bunch of his nearby friends and neighbors.
than a single subnet if current business models are an example of their plans for the future.
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 theHaving fewer options is going to be easier for the ISP, I suspect.
ARIN policy process is usually not appreciated by them. Owen
Current thread:
- Re: v6 subnet size for DSL & leased line customers, (continued)
- Re: v6 subnet size for DSL & leased line customers Mark Smith (Dec 20)
- Re: v6 subnet size for DSL & leased line customers Kevin Oberman (Dec 20)
- Re: v6 subnet size for DSL & leased line customers Deepak Jain (Dec 20)
- Re: v6 subnet size for DSL & leased line customers Joe Greco (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Owen DeLong (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Chris Adams (Dec 21)
- Message not available
- Re: v6 subnet size for DSL & leased line customers Chris Adams (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Robert E. Seastrom (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Deepak Jain (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Mark Smith (Dec 20)
- Re: v6 subnet size for DSL & leased line customers Joe Greco (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Owen DeLong (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Joe Greco (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Randy Bush (Dec 21)
- Re: v6 subnet size for DSL & leased line customers Joel Jaeggli (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Randy Bush (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Joel Jaeggli (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Randy Bush (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Joel Jaeggli (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Randy Bush (Dec 22)
- Re: v6 subnet size for DSL & leased line customers Iljitsch van Beijnum (Dec 23)
- Re: v6 subnet size for DSL & leased line customers sthaug (Dec 23)