On Thu, 20 Dec 2007 12:26:43 +0900 Randy Bush <randy@psg.com> wrote:

...

I work on a network with 100K+ DSL folks and 200+ leased line customers, plus some other stuff. The leased line customers are increasing dramatically. I should plan for a /64 for every DSL customer and a /48 for every leased line customer I expect over the next 5-7 years?

why not a /56 by default for both, and give them an opportunity to justify more?

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.

a /64 is a bit old-think unless you are having cost issues getting your space from above.

Agree. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

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. :) 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!?" Its up to the ISP or LIR with minimum recommendations. "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 6.4.4 and for the purposes of measuring utilization as defined in this document." :) Deepak

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

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

...

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.

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.

Except we're primarily discussing what are almost certain to be small networks here, so there's probably not even any significant concern about this.

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.

Yes, and just how many of those business networks actually involve more than a handful of networks with a DSL-class upstream connection? Let's not get confused here. I don't ever see large enterprises hanging off residential broadband Internet connections, and quite frankly, if they try, I'm not that concerned about how easy it is for them to manage.

...

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.

No, I'm not.

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.

I look at the practical realities. Let's look at the big IPv6 picture. It is unlikely that there will be wide acceptance of the ability to create ad-hoc routed topologies in many environments; controlled-access corporate environments certainly represent one such environment. That implies that the capability to do bridging (or, if you prefer, switching) will remain as a virtually mandatory option. Creating a hierarchical routed topology certainly seems and sounds nice, and in fact, I'm all in favor of it, but I don't actually expect that it's going to be the default.

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",

You aren't?

the routing topology will mostly handle itself automatically, although,

Oh, you are, you're just pretending you aren't. I see.

people may wish to intervene to design the security policy or at least have the ability to modify it from the default.

But that's pretty much something that we could and should want regardless. Honestly, how hard would it be, today, to build a little switch-widget that implemented access controls to various ports? And if you do that, does it matter if it's happening on a "router" or on a switch? (hint: answer is "it does not, really, though it may blow the minds of traditionalists.")

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

No, actually, I'm not really thinking IPv-anything. I'm thinking more in terms of network blobs and how they interrelate. I could just as easily say that you're applying traditionalist network design paradigms to next-generation networks, when in fact that may not be the right thing to do.

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.

Your average home user isn't going to know about any of that. He's going to have his Netgear (or pick your $fav vendor) smartthing that either routes or switches at Layer 2 or Layer 3, depending. Ultimately, what /he/ is going to want to do is to see a little interface come up, that displays a little graphic view of his network, lets him click on a device, and set security policy. He'll want to be able to set "Vista PC" to access "Everything". He'll want to be able to set "Home Media Server" to access "Local Only". He'll want to be able to set "Vonage VoIP Adapter" to access "Specific Network Only." He isn't going to know or care about your "security policy design," he isn't going to be engaging in any serious "troubleshooting," and he's going to rely on the logic in the device to determine if the policy is even enforceable (which /can/ be determined). He isn't going to be concerned about, or even want to be concerned about, L2 vs L3 or where the firewalling takes place. He's going to expect his device to be smart enough to tell him what he needs to do, and whether the underlying network is one thing or another isn't a serious consideration. You simply have to realize that L2 and L3 aren't as different as you seem to think. You can actually consider them flip sides of a coin in many cases.

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.

So, as I said...

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

/Possibly/. It would be much more likely to be that way if everyone was issued large CIDR blocks, every router was willing to delegate a prefix, and there was no call for bridging.

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

I'm skeptical, but happy to be proven wrong someday.

...

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.

We'll see. ... 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.

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

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

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

On 23 dec 2007, at 7:07, Joel Jaeggli wrote:

If you mean there's no detent between /48 and /56

What does "no detent between..." mean?

If you're asking why ipng doesn't incorporate the lessons of cidr

What lessons would that be? On 23 dec 2007, at 7:59, Mikael Abrahamsson wrote:

Does IPv6 capable CPEs have the possibility to source packets from local network (received via pd) and only have FE80: IP for upstream routing which is never used as an SRC address for communication with the outside world (apart from upstream router)?

IPv6 routing protocols allow this, yes. I can't remember if I tried it with Cisco's prefix delegation but I'm fairly confident it would work for that, too. On 23 dec 2007, at 9:49, Mohacsi Janos wrote:

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

Hm, I haven't heard that argument used against DHCPv6. (On principle, I'm against doing something that's technically suboptimal because it's easier organizationally, though.) Having a default router in DHCPv6 would be a mistake because if the DHCPv6 server isn't also the default router, this introduces an opportunity for failures that isn't there with router advertisements. I've heard people argue that prefixes should be in RAs for much the same reason and therefore it's a good thing that DHCPv6 doesn't know about the prefix _length_ but that doesn't convince me: if you give someone an address, you impliccitly also give them a prefix, so it makes no sense to withhold the prefix length and require another protocol to learn this information. On 23 dec 2007, at 10:03, Randy Bush wrote:

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?

The difference is that for IPv4, it's DHCP or manual configuration. With IPv6, you also have stateless autoconfig using router advertisements. So it's no so much what DHCPv6 does that IPv4 DHCP doesn't do, but what you can do without DHCPv6 that you couldn't do without DHCP in IPv4. In small IPv4 networks the DHCP server runs on the router so there is fate sharing, but this doesn't work well if there is more than one router. In that case you'll soon be running a DHCP server that's separate from the routers and thus opening up a new failure mode. With RAs hosts get the same address regardless of which router they happen to talk to so it's a lot more robust than either the single router model or the separate DHCP server model.

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

What I hear is that enterprise admins want DHCPv6 because they want to have control. Me, I want to run a DHCPv6-free network because RAs give me what I want and more protocols just means more headaches. On 23 dec 2007, at 18:54, Ross Vandegrift wrote:

...

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.

The idea is that your interface identifier that you create locally from a MAC address is unique. With less than 46 bits that's not going to happen. Unforatunately, the 17 or 18 bits that you don't need for this are in the middle. But at some point in the future we can revist this and free up 16 bits so anyone with a /64 can create 65535 fresh subnets out of nothing, which is good insurance against possible bad address allocation policies. Note that there's duplicate address detection but that only _detects_ the problem and doesn't fix it if there are duplicate addresses. On 23 dec 2007, at 21:44, David Barak wrote:

How about this for a modest proposal for a capability: Allow autoconfigured generation of IPv6 interface addresses to use this format:

(one byte VLAN ID) (48 bit MAC address)

What I always tell people is to do it like this: <given /48 bits>:<decimal VLAN ID>:</64 subnet> I.e., VLAN 288 would be something like 2001:db8:31:288::/64 If you then also tell routers to fill in the bottom 64 bits with an EUI-64, your configs are extremely straightforward. -- I've written another book! http://www.runningipv6.net/

On Dec 23, 2007 1:21 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

...

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

What I hear is that enterprise admins want DHCPv6 because they want to have control. Me, I want to run a DHCPv6-free network because RAs give

not control, but 'the same functionality and capabilities as exist today' (which is atleast resolver definitions, default-gw, ip-addressing, equipment/asset tracking... more)

me what I want and more protocols just means more headaches.

and trying to keep 50k machines updated with proper resolvers (in the simplest example) is easier with RA than DHCP how? Seriously, its head-out-of-sandpile time here. Enterprise admins and dsl/cable-modem folks use DHCP today so that they can have some flexibility to migrate their services around if there are issues, concerns, or new/better platforms that could be taken advantage of by their users. If you do not provide that level of flexibility with the same (or better hopfully) overhead you've lost the game. If your 'network' is 5 machines in a basement all with ssh+root then this conversation doesn't matter. If your network is a 50k+ mixed platform global enterprise network you are F'd with a capital F if you have to spend cycles running to all 50k+ machines to update their resolver settings (in just the simplest of examples). -Chris

On Dec 23, 2007 8:44 PM, Randy Bush <randy@psg.com> wrote:

...

and trying to keep 50k machines updated with proper resolvers (in the simplest example) is easier with RA than DHCP how?

do you really mean skip RA or all of autoconf?

I think what makes sense is to use the parts of ipv6 that work well, RA, but blend in what works already well and is folded already into the enterprise model... dhcpv6.

i want to explore RA(only) + DHCP, to save me from running a routing protocol or vsrp to have redundant exits for a LAN.

ok, somewhere there's a blend of things that will work for enterprises and cable/dsl/mso folk. I think that some enterprises don't mind 'random address selection' while they want to pass out info required (cause like it or not DNS is required) in a sane manner, one that's even part of their current method. RA/Autoconf won't work at all for some folks with deployed server infra, all they want is a method to get a static addr on a box and route properly. Perhaps RA gets them the 'route properly' part easily enough but I can imagine places where that is even turned off. Basically my rant here is that autoconf isn't enough, it's not even a starting point for enterprise folks who rely on DHCP for all it's bells + whistles. Taking a giant leap backwards is never going to fly for them, so wake up and smell the cafe, dhcpv6 needs to be viable, workable, operable, built-in and well tested.

randy, about to go off net, heading for a rural onsen & ryokan

have fun! -Chris

On 24 dec 2007, at 20:00, Kevin Loch wrote:

...

RA/Autoconf won't work at all for some folks with deployed server infra,

That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers.

Hopefully vrrpv6 will work with RA turned completely off.

With router advertisements present you don't need VRRP because you have dead neighbor detection.

On Dec 24, 2007, at 9:43 PM, Kevin Loch wrote:

Iljitsch van Beijnum wrote:

...

On 24 dec 2007, at 20:00, Kevin Loch wrote:

...

...

RA/Autoconf won't work at all for some folks with deployed server infra, That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers. Hopefully vrrpv6 will work with RA turned completely off. With router advertisements present you don't need VRRP because you have dead neighbor detection.

And that helps the hosts on the same l2 segment that need different gateways how? Or hosts with access to multiple l2 segments with different gateways?

I think the point is that RA and VRRPv6 are not designed to depend on each other in any way. While you can certainly run both on any given segment, it is hard to imagine many cases where one would want to do so. In places where all you need is to know a valid gateway that can do the right thing with your packets, RA is probably the right solution. This, generally, turns out to be the vast majority of LAN segments. Clearly, RA is intended only for scenarios where a gateway is a gateway is a gateway. In places where you need tighter control over the usage of various gateways on a common L2 segment, VRRP probably makes more sense. However, as things currently stand, that means static routing configuration on the host since for reasons passing understanding, DHCP6 specifically won't do gateway assignment. I don't know the state of the current VRRP6 draft or protocol, but, I can't imagine what would be left in VRRP6 if it couldn't be statically configured without RA. If that's the case, then, what would it possibly do, exactly, that would be different from RA without VRRP? Owen

Thus spake <sthaug@nethelp.no>

...

In places where you need tighter control over the usage of various gateways on a common L2 segment, VRRP probably makes more sense. However, as things currently stand, that means static routing configuration on the host since for reasons passing understanding, DHCP6 specifically won't do gateway assignment.

For those of us with lots of IPv4 customers dependent on DHCP, it would be good to know more detail about this point. What is the problem, and are there plans to do anything about it in DHCPv6?

For most hosts, there is no need for anything like VRRP or getting a default gateway via DHCP in v6 because all hosts are required to implement RA/RS. The vast majority of hosts either have one default gateway or two-plus equivalent ones, so that works fine. For hosts with multiple gateways that are unequal, VRRP+DHCP doesn't solve the problem any better than RA/RS; you have to fiddle with the hosts' routing tables to get things set up right. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote:

RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer

I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway. Having not looked in great detail, I am unclear if IPv6 has done something to fix this concern or not. Is this feature going to get turned off when the first worm comes along that spoofs RA's -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:

In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote:

...

RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer

I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway.

Having not looked in great detail, I am unclear if IPv6 has done something to fix this concern or not.

Is this feature going to get turned off when the first worm comes along that spoofs RA's

It's unlikely that it will matter. In practice, ICMP router discovery died a long time ago, thanks to neglect. Host vendors didn't adopt it, and it languished. The problem eventually got solved with HSRP and its clone, VRRP. This doesn't resolve the real underlying problem: Ethernet is inherently insecure. MAC addresses can be forged, protocols (ARP, ND) can be forged and at this point, there's not much that we can do about it. Architecturally, we need authentication over each and every control plane packet sent. Getting there without invoking the full complexity of a public key infrastructure is still an unsolved problem, AFAIK. Tony

In a message written on Wed, Dec 26, 2007 at 09:19:54PM +0100, Iljitsch van Beijnum wrote:

Many switches can enforce a MAC/port relationship, so that MAC addresses can't be spoofed.

Which gets to the crux of my question. If you're a shop that uses such features today (MAC/Port tracking, DHCP snooping, etc) to "secure" your IPv4 infrastructure does IPv6 RA's represent a step backwards from a security perspective? Would IPv6 deployment be hindered until there is DHCPv6 snooping and DHCPv6 is able to provide a default gateway, a-la how it is done today in IPv4? It would be very interesting to me if the answer was "it's moot because we're going to move to CGA's as a step forward"; it would be equally interesting if the answer is "CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem." -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information.

Which is probably going to make IPv6 deployment slower in service provider environments.

There's also tons of ways to complicate your life by mixing stateless autoconf and DHCPv6, especially since most systems don't support DHCPv6 unless you install additional software. Last but not least, DHCPv6 has a stateful mode that's appropriate for address assignment or prefix delegation, and a stateless mode that's more efficient for the configuration of information that's not client-specific. Unfortunately, it's up to the client to initiate the desired mode. Then there are the M and O bits in RAs that tell you whether to do DHCPv6 but a number of DHCPv6 aficionados look like they want to ignore those bits.

Again, this is something that's going to slow down deployment in service provider environments. Providers are comfortable with the IPv4 DHCP model (which is definitely not stateless) and many of us would like to keep this.

What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering.

"Configure this stuff manually" may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

...

"Configure this stuff manually" may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers.

Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers.

It wouldn't be a subnet with a million customers, of course. We would typically have aggregation routers handling 5000 to 30000 customers, each connected via (in our case) point to point DSL links. Important point here is that we *don't* want per-customer IPv4 (or IPv6) config on the aggregation routers - this is what we have DHCP servers for.

If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know.

I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE which provides configuration to hosts on its LAN side sounds like a reasonable model. It requires the customer to have a CPE with actual *router* functionality, as opposed to just a bridge. This is different from today's requirements, but may not be unreasonable. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Thu, 27 Dec 2007 12:11:54 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 27 dec 2007, at 11:57, sthaug@nethelp.no wrote:

...

"Configure this stuff manually" may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers.

Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers.

If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know.

I haven't had a chance to test it, but according to "Deploying IPv6 Networks", IOS can support DHCPv6 based prefix delegation. It even supports multiple downstream interfaces on the CPE - you configure the subnet number you want on each of the interfaces, and the CPE will configure the DHCP-PD learned /48 on the front of them automatically and then start announcing those prefixes in RAs out those interfaces. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van Beijnum wrote:

100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information.

I would note, it's not too late to fix these problems. We don't have wide spread IPv6 deployment yet, and I can't imagine it's all that hard to send a default gateway in DHCPv6, for example. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

On Dec 27, 2007 5:27 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations.

first implementations, in a protocol that's 'fully baked' (according to ietf closing down the v6 WG) and been in 'production' for 15 years? for features that have existed in the v4 network for 5+ years? ouch... This gets back to my point about having feature parity and the fact that that is important. People have deployed rather large environments that require these features, not having them is a step backwards and painful for the operators in question.

What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of

'the largest deployed platform' already has this built-in, yes? (vista/xp)

configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's

you are crazy... seriously, have you walked around to 10k or 50k machines or attempted to get helpdesky people to do the same? have you considered that this all works fine in v4, is tied into my OSS backends and is a part of my business process? Getting some new software (firefox is a fine example) deployed to 50k workstations is an overnight event... SMS (or whatever the new MS equivalent is) rolls out the software update, there are many other options (tivoli, ca-unicenter, custom-foo) which will also do this work for you, getting proper and dynamic setup of IP info (my earlier example of resolvers) isn't quite as simple unless you use dhcp.

not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering.

sure, like deploy v6... wait, that doesn't do it either :( It's not just renumbering, it's migration of services which the network elements are reliant on (dns, wins, tftp-root/nfs-root...) tieing my laptop to the same addr each time for some process including logs and HR details and SoX compliance perhaps. This is a bighairy beast, just saying 'dhcpv6 isnt possible use autoconf' is never going to be acceptable.

That being said, please go to your vendors and tell them what you need. Preferably at a high level, so they can provide the functionality in the optimal way, rather than just revert back to the IPv4 way of doing things.

also be sure to let your standards body(s) know that some form of feature parity is relevant. I think often there is a missing message between operators and the other folks :( this clearly (to me atleast) seems like one of those areas. -Chris

On Thu, 27 Dec 2007 22:57:59 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 27 dec 2007, at 20:26, Christopher Morrow wrote:

<snip>

Taken to its extreme "feature parity" means a search and replace of all IPv4 specs to make every instance of "32 bits" "128 bits" but not changing anything else. That's not what IPv6 is.

Exactly. IPv6 is similar enough to IPv4 that it makes it easier to learn than if it were a completely new and unrelated protocol. It's different enough that you need to take each of the concepts and practices that you know and have used for IPv4 for many years and try to objectively evaluate whether they're still valid for IPv6. IPv6 has features that IPv4 has never had, but have existed in IPX and Appletalk since they were designed many years ago. If people have the time, learning about those protocols might help with more easily learning about IPv6. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of "routers" to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of "routers" with this "non-network core" data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of "routers".) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message:

From: Leo Bicknell <bicknell@ufp.org> Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group <nanog@merit.edu> Subject: Re: v6 subnet size for DSL & leased line customers

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote:

...

It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers.

Really. I didn't know RA's could:

- Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not manually configure.

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

James R. Cutler james.cutler@consultant.com

Leo Bicknell <bicknell@ufp.org> writes:

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote:

...

It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers.

Really. I didn't know RA's could:

- Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not manually configure.

I'm running (native) IPv6 at home, and in the colo too. Most of my ssh sessions to personally owned machines go over v6. My laptops (with a single exception) are Macs. You may not be aware that the Mac is fairly smart about which interface it uses for connections - it will prefer the gigabit ethernet to the wireless when it sees link... it prefers wireless to dialup too. Basically, whenever you establish a new outgoing session it will use the "lowest cost" interface to do the deed. For IPv4, I have the same address manually assigned on the DHCP server to both the gigabit ethernet's MAC address and the wireless interface's MAC address. This means that when I plug into the gige, as I do for filesharing or backing some files up, the Mac uses the gigabit ethernet. When I unplug and carry the Mac to the conference room, *all existing upper layer sessions are preserved* - TCP and friends are blissfully unaware that a change has taken place; one gratuitous arp so the router knows where to send the packets and we're on our way again with nary a hiccup. I don't have an ssh session croak just because I connected or disconnected a cable. I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so). Anyone from Apple reading this list? :-) ---Rob

On Thu, 27 Dec 2007 21:50:01 -0500 "Robert E. Seastrom" <rs@seastrom.com> wrote:

Leo Bicknell <bicknell@ufp.org> writes:

<snip>

I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so).

Don't know if Mac's can do bridging, but under Linux, all you'd need to do would be create bridge instance, assign the two or more interfaces to the bridge, and have DHCPv6 use the bridge virtual interface. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

Tony Li wrote:

On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:

It's unlikely that it will matter. In practice, ICMP router discovery died a long time ago, thanks to neglect. Host vendors didn't adopt it, and it languished. The problem eventually got solved with HSRP and its clone, VRRP.

Its been available from microsoft since windows2000, and according to documentation, on by default. I am not quite sure this can be blamed on vendors as opposed to users. http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry...

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.

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.

I thought we were all trying to discourage NAT in IPv6. Clearly, NAT solves the problem ... while introducing 1000 new ones. :-/ ... 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.

Joel Jaeggli wrote:

equipment makers (as much as randy hates them)

excuse?!?!? that is unjustified and uncalled for. vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. randy

If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. It's not clear to me where their needs don't coincide in this case.

there are three legs to the tripod

network operator user equipment manufacturer

They have (or should have) a mutual interest in:

Transparent and automatic configuration of devices. The assignment of globally routable addresses to internet connected devices the user having some control over what crosses the boundry between their network and the operators.

Yes, well, that sounds fine, but I think that we've already hashed over at least some of the pressures on businesses in this thread. I've tried to focus on what's in the Subject:, and have mostly ignored other problems, which would include things such as cellular service, where I suspect that the service model is such that they'll want to find a way to allocate users a /128 ... There is, further, an effect which leads to "equipment mfr" being split into "netwk equipment mfr" and "cpe equipment mfr", because the CPE guys will be trying to build things that'll work for the end user, working around any brokenness, etc. The problem space is essentially polarized, between network operators who have their own interests, and users who have theirs. So, as /engineers/ for the network operators, the question is, what can we do to encourage/coerce/force the businesses on our side of the equation to allocate larger rather than smaller numbers of bits, or find other solutions? What could we do to encourage, or better yet, mandate, that an ISP end- user connection should be allocated a minimum of /56, even if it happens to be a cellular service? ( :-) ) What do we do about corporate environments, or any other environment where there may be pressure to control topology to avoid "DHCP PD" to devices added to the network on an ad-hoc basis? Is it actually an absolutely unquestionable state of affairs that the smallest autoconfigurable subnet is a /64? Because if not, there are options there ... but of course, that leads down a road where an ISP may not want to allocate as much as a /64 ... What parts of this can we tackle through RIR policy? RFC requirements? Best practice? Customer education? ( :-) ) Other ideas? ... 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.

Randy Bush wrote:

...

...

vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4.

i presume you mean nat v6/v6. this would be a real mess and i don't think anyone is contending it is desirable. but this discussion is ostensibly operators trying to understand what is actually appropriate and useful for a class of customers, i believe those of the consumer, soho, and similar scale.

to summarize the positions i think i have heard o one /64 subnet per device, but the proponent gave no estimate of the number of devices o /48 o /56 o /64

It plausible that if one were to assign a single /64 and reserve a 56 to delegate per customer that you could number about 16 million customers per /32 with a few hundred thousand /64s remaining for infrastrucuture. size of an agregate for a pop might be /48 (~250 customers) to /40 (65k customers) to /36 (1 million customers) A large retail isp might under those circumstances be able to get away with order of /28 to /30 in total.

the latter three all assuming that the allocation would be different if the site had actual need and justification.

personally, i do not see an end site needing more than 256 subnets *by default*, though i can certainly believe a small minority of them need more and would use the escape clause. so, if we, for the moment, stick to the one /64 per subnet religion, than a /56 seems sufficient for the default allocation.

personally, i have a hard time thinking that any but a teensie minority, who can use the escape clause, need more than 256. hence, i just don't buy the /48 position.

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 Fri, 21 Dec 2007 08:31:07 -0800 Owen DeLong <owen@delong.com> 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.

...

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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

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

On Dec 22, 2007 12:23 PM, Ross Vandegrift <ross@kallisti.us> wrote:

On Fri, Dec 21, 2007 at 01:33:15PM -0500, Deepak Jain wrote:

...

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 ?

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.

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 :( Somewhere along the path to ipng we got reverted to classful addressing again :( -Chris

Christopher Morrow wrote:

On Dec 22, 2007 12:23 PM, Ross Vandegrift <ross@kallisti.us> wrote:

...

...

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 ? I am confused on this point as well. IPv6 documents seem to assume

On Fri, Dec 21, 2007 at 01:33:15PM -0500, Deepak Jain wrote: 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.

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 :( Somewhere along the path to ipng we got reverted to classful addressing again :(

I think this is the point I was trying to make. Just because we have "so many bits" now... why does the equipment/software need to get "stupider" again? Are we going to have an IPv6 CIDR initiative again (15 years from now) to recover all of that wasted space from "early" allocations).. Merry Christmas, and junk. Deepak

On Sun, 23 Dec 2007, Iljitsch van Beijnum wrote:

On 22 dec 2007, at 21:23, Ross Vandegrift wrote:

...

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

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.

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

On Sun, 23 Dec 2007, Randy Bush wrote:

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?

Actually we are using stateless form of DHCPv6 to announce DNS servers with autoconf + static address comfiguration for servers. This is satisfactory for a small organisation like us (less than 40 persons). We are testing DHCPv6 also. For a larger organisation (>1000 computer) I will ask my colleagues about their DHCPv6 experiences.... Best Regards, Janos Mohacsi

On Sun, 23 Dec 2007 12:54:34 -0500 Ross Vandegrift <ross@kallisti.us> wrote:

On Sun, Dec 23, 2007 at 12:24:32AM +0100, Iljitsch van Beijnum wrote:

...

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.

If operational simplicity of fixed length node addressing is a technical reason, then I think it is a compelling one. If you've ever done any reasonable amount of work with Novell's IPX (or other fixed length node addressing layer 3 protocols (mainly all of them except IPv4!)) you'll know what I mean. I think Ethernet is also another example of the benefits of spending/"wasting" address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/"waste" bits on addressing to get operational convenience - "plug and play" layer 2 networking. If IPv6 can have the same operational simplicity as Ethernet, and addressing bits can afford to be spent on it, then I think those bits are well worth spending. The /64 for all subnets idea is probably an example of "worse is better" principle. It's not ideal for everything, but because it's general enough, it works with everything, and is simpler and a *single* solution to everything, and that's what makes it better. Regarding where the /64 boundary came from, from what I understand, the following Internet Drafts are it's origin: "8+8 - An Alternate Addressing Architecture for IPv6" http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt "GSE - An Alternate Addressing Architecture for IPv6" http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt

...

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.

-- Ross Vandegrift ross@kallisti.us

"The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

On Sun, 23 Dec 2007 17:26:12 -0600 (CST) Joe Greco <jgreco@ns.sol.net> wrote:

...

If operational simplicity of fixed length node addressing is a technical reason, then I think it is a compelling one. If you've ever done any reasonable amount of work with Novell's IPX (or other fixed length node addressing layer 3 protocols (mainly all of them except IPv4!)) you'll know what I mean.

I think Ethernet is also another example of the benefits of spending/"wasting" address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/"waste" bits on addressing to get operational convenience - "plug and play" layer 2 networking.

The difference is that it doesn't "cost" anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses.

With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful.

I don't think there is that difference at all. MAC address allocations are paid for by the Ethernet chipset/card vendor, and I'm pretty sure they have to justify their usage before they're allowed to buy another block. I understand they're US$1250 an OUI, so something must have happened to prevent somebody buying them all up to hoard them, creating artificial scarcity, and then charging a market sensitive price for them, rather than the flat rate they cost now. That's not really any different to an ISP paying RIR fees, and then indirectly passing those costs onto their customers.

This will compel ISP's to at least consider the issues, and it will most likely force users to buy into technologies that allow them to do what they want. And inside a /64, you have sufficient space that there's probably nothing you can't do. :-)

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

-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

On Sun, 23 Dec 2007 19:27:55 -0600 (CST) Joe Greco <jgreco@ns.sol.net> wrote:

...

...

...

I think Ethernet is also another example of the benefits of spending/"wasting" address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/"waste" bits on addressing to get operational convenience - "plug and play" layer 2 networking.

The difference is that it doesn't "cost" anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses.

With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful.

I don't think there is that difference at all. MAC address allocations are paid for by the Ethernet chipset/card vendor, and I'm pretty sure they have to justify their usage before they're allowed to buy another block. I understand they're US$1250 an OUI, so something must have happened to prevent somebody buying them all up to hoard them, creating artificial scarcity, and then charging a market sensitive price for them, rather than the flat rate they cost now. That's not really any different to an ISP paying RIR fees, and then indirectly passing those costs onto their customers.

MAC address allocations are paid for by the Ethernet chipset/card vendor.

They're not paid for by an ISP, or by any other Ethernet end-user, except as a pass-through, and therefore it's considered a fixed cost. There are no RIR fees, and there is no justification. You buy a gizmo with this RJ45 and you get a unique MAC. This is simple and straightforward. If you buy one device, you get one MAC. If you buy a hundred devices, you get one hundred MAC's. Not 101, not 99. This wouldn't seem to map well at all onto the IPv6 situation we're discussing.

How many ISP customers pay RIR fees? Near enough to none, if not none. I never have when I've been an ISP customer. Why are you pretending they do? I think your taking an end-user perspective when discussing ethernet but an RIR fee paying ISP position when discussing IPv6 subnet allocations. That's not a valid argument, because you've changed your viewpoint on the situation to suit your position. Anyway, the point I was purely making was that if you can afford to spend the bits, because you have them (as you do in Ethernet by design, as you do in IPv6 by design, but as you *don't* in IPv4 by design), you can spend them on operational convenience for both the RIR paying entity *and* the end-user/customer. Unnecessary complexity is *unnecessary*, and your customers won't like paying for it if they discover you've chosen to create it either on purpose or through naivety.

With an IPv6 prefix, it is all about the prefix size. Since a larger allocation may cost an ISP more than a smaller allocation, an ISP may decide that they need to charge a customer who is allocated a /48 more than a customer who is allocated a /64.

I don't pay anyone anything for the use of the MAC address I got on this free ethernet card someone gave me, yet it is clearly and unambiguously mine (and only mine) to use. Does that clarify things a bit?

If you are proposing that RIR's cease the practice of charging different amounts for different allocation sizes, please feel free to shepherd that through the approvals process, and then I will certainly agree that there is no longer a meaningful cost differential for the purposes of this discussion. Otherwise, let's not pretend that they're the same thing, since they're clearly not.

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

-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

Joe Greco wrote: [..]

Okay, here, let me make it reaaaaaaallllllyyyyy simple.

Yes, indeed lets make it reaaaaaaallllllyyyyy simple for you:

If your ISP has been delegated a /48 (admittedly unlikely, but possible) for $1,250/year, and they assign you a /56, their cost to provide that space is ~$5. They can have 256 such customers.

Fortunately ISP's get their space per /32 and up based on how much they can justify, which is the amount of customers they have. As such for a /32 single /48 is only (x / 65k) = like 20 cents or so? And if you are running your business properly you will have more clients and the price will only go down and down and down. Really (or should I write "reaaaaaaallllllyyyyy" to add force?) if you as an ISP are unable to pay the RIR fees for that little bit of address space, then you definitely have bigger problems as you won't be able to pay the other bills either. How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical! As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel. For some magic reasons though(*), it seems to be completely ludacrist to do it this way, even though it would make the bill very clear and it would charge the right amount for the right things and not some arbitrary number for some other arbitrary things and then later complaining that people use too much bandwidth because they use bittorrent and other such things. For the cable folks: make upstream bandwidth more pricey per class than downstream, problem of heavy-uploaders solved as they get charged. Greets, Jeroen (* = then again I don't have an mba or something like that so I prolly miss out an all kinds of important factors why people have to make it so complex)

Joe Greco wrote: [..]

...

Okay, here, let me make it reaaaaaaallllllyyyyy simple.

Yes, indeed lets make it reaaaaaaallllllyyyyy simple for you:

...

If your ISP has been delegated a /48 (admittedly unlikely, but possible= ) for $1,250/year, and they assign you a /56, their cost to provide that space is ~$5. They can have 256 such customers.

Fortunately ISP's get their space per /32 and up based on how much they can justify, which is the amount of customers they have.

As such for a /32 single /48 is only (x / 65k) =3D like 20 cents or so? And if you are running your business properly you will have more clients and the price will only go down and down and down.

Really (or should I write "reaaaaaaallllllyyyyy" to add force?) if you as an ISP are unable to pay the RIR fees for that little bit of address space, then you definitely have bigger problems as you won't be able to pay the other bills either.

There's a difference between "unable to pay the RIR fees" and "do not deem any business value in spending the money." Engineers typically feel that businesses should be ready and willing to spend more money for reasons that the average business person won't care about. Pretend I'm your CFO. Explain the value proposition to me. Here's the (slightly abbreviated) conversation. "Well, you say we need to spend more money every year on address space. Right now we're paying $2,250/year for our /32, and we're able to serve 65 thousand customers. You want us to start paying $4,500/year, but Bob tells me that we're wasting a lot of our current space, and if we were to begin allocating less space to customers [aside: /56 vs /48], that we could actually serve sixteen million users for the same cash. Is there a compelling reason that we didn't do that from the outset?" This discussion is getting really silly; the fact of the matter is that this /is/ going to happen. To pretend that it isn't is simply naive.

How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical!

Perhaps end-user ISP's don't charge by bandwidth usage...

As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel.

Sure, but that's mostly fantasyland. The average ISP is going to want to monetize the variables. You want more bandwidth, you pay more. You want more IP's, you pay more. This is one of the reasons some of us are concerned about how IPv6 will /actually/ be deployed ... quite frankly, I would bet that it's a whole lot more likely that an end-user gets assigned a /64 than a /48 as the basic class of service, and charge for additional bits. If we are lucky, we might be able to s/64/56/. I mean, yeah, it'd be great if we could mandate /48 ... but I just can't see it as likely to happen.

For some magic reasons though(*), it seems to be completely ludacrist to do it this way, even though it would make the bill very clear and it would charge the right amount for the right things and not some arbitrary number for some other arbitrary things and then later complaining that people use too much bandwidth because they use bittorrent and other such things. For the cable folks: make upstream bandwidth more pricey per class than downstream, problem of heavy-uploaders solved as they get charged.

Sure, but that's how the real world works. The input from engineering folks is only one small variable in the overall scheme of things. It is a /mistake/ to assume that cost-recovery must be done on a direct basis. There's a huge amount of business value in being able to say "unlimited(*) Internet service for $30/mo!" The current offerings in many places should outline this clearly. So, the point is, as engineers, let's not be completely naive. Yes, we /want/ end-users to receive a /56, maybe even a /48, but as an engineer, I'm going to assume something more pessimistic. If I'm a device designer, I can safely do that, because if I don't assume that a PD is going to be available and plan accordingly, then my device is going to work in both cases, while the device someone who has relied on PD is going to break when it isn't available. ... 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.

Right... Let's look at this in detail:

/48 per customer == 65,536 customers at $2,250 == $0.03433/customer /56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer

So, total savings per customer is $0.0342/customer _IF_ you have 16,777,216 customers. On the other hand, sir, for those customers who need more than 256 subnets, we're running the risk of having to assign them multiple noncontiguous prefixes.

Okay, here's a problem. You keep making these statements which bear no resemblance to the real world. If I "need more than 256 subnets", and I approach my ISP to ask for such, there are at least two obvious answers which are incredibly more likely than any risk of "assign[ing] them[me] multiple noncontiguous prefixes." Answer 1: "We don't provide more space on your Cableco Cable Modem Service. If you would like, we do offer Cableco Business Class Service." Answer 2: "We can assign you a larger prefix, however, you'll need to power cycle the cable modem and your addresses will change." Remember, this is residential broadband. Saying /no/ is fairly common (in the same way that I can't get custom PTR DNS for a static IP address on a resi connection with many service providers.)

Although the cost of doing so is not readily apparent, each router has a limit to the number of prefixes that can be contained in the routing table.

Yeah, well, I'm not impressed. As an operator community, we've been so good about getting our own affairs in order there.

The cost of upgrading all of our routers later probably far exceeds the $0.03 per customer that we would save. Really, in general, I think that the place to look for per-customer savings opportunities would be in places where we have a potential recovery greater than $0.03 per customer.

How about /not/ upgrading all of your routers and keeping the "$0.03 per customer"?

...

This discussion is getting really silly; the fact of the matter is that this /is/ going to happen. To pretend that it isn't is simply naive.

...

How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical!

Perhaps end-user ISP's don't charge by bandwidth usage...

True, but, they don't, generally, charge by the address, either. Usually, they charge by the month. If you can't cover $0.03/year/ customer for address space in your monthly fees, then, raise your monthly fee by $0.05. I'm betting your customers won't care.

Customers at the low end of the spectrum do in fact care, and my guess would be that they'd rather save the nickel than get extra address space that only 1 in 1,000 of them might ever get around to using.

...

...

As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel.

Sure, but that's mostly fantasyland. The average ISP is going to want to monetize the variables. You want more bandwidth, you pay more. You want more IP's, you pay more. This is one of the reasons some of us are concerned about how IPv6 will /actually/ be deployed ... quite frankly, I would bet that it's a whole lot more likely that an end-user gets assigned a /64 than a /48 as the basic class of service, and charge for additional bits. If we are lucky, we might be able to s/64/56/.

I mean, yeah, it'd be great if we could mandate /48 ... but I just can't see it as likely to happen.

I'm betting that competition will drive the boundary left without additional fees. After all, if you're only willing to dole out /64s and your competitor is handing out /56 for the same price, then all the customers that want multiple subnets are going to go to your competitor. The ones that want /48s will find a competitor that offers that.

Ah! That's good. Now we're making some progress. The first question most businesses have when they're spending money is "how much is it." Not "how much is it on a per-customer basis." If I go and ask for a new $2000 server so that I can put up some neat new thing, such as a reverse-traceroute webserver, the idea is that I should need to justify why it can't be done on an existing webserver. Maybe it can, but maybe it can't (let's say because it'll connect out to our routers and the security risk warrants a separate server). The fact that it might only cost a penny per month per customer is irrelevant to the higher-level analysis. In the same way, if an ISP can avoid spending money, there are almost certainly some who will do so. Since the average customer is likely to be more than adequately served by 256 subnets for the foreseeable future, there will undoubtedly be some that allocate /56's (or even /64's). Market pressures, the actual needs of consumers, and whether or not it actually winds up as cheaper to support a single address space size on backroom systems will all work to shape what actually happens.

...

So, the point is, as engineers, let's not be completely naive. Yes, we /want/ end-users to receive a /56, maybe even a /48, but as an engineer, I'm going to assume something more pessimistic. If I'm a device designer, I can safely do that, because if I don't assume that a PD is going to be available and plan accordingly, then my device is going to work in both cases, while the device someone who has relied on PD is going to break when it isn't available.

Assuming that PD is available is naive. However, assuming it is not is equally naive.

No, it's not equally naive. The bridging scenario is likely to work in all cases, therefore, assuming bridging as a least common denominator is actually pretty "smart" - even though I would prefer to see a full implementation that works in all cases. Assume the worst, hope for the best. If that's "naive", well, then it's all a lost cause. You can call it "coldly cynical" all you'd like, though. ;-)

The device must be able to function in both circumstances if possible, or, should handle the case where it can't function in a graceful and informative manner.

That much is certain. ... 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.

Leigh Porter wrote:

Wow, is this what you folks do at Christmas ?

Clearly you yourself are affectionate about this thing called Christmas, if you are so affectionate about it, then why are you making silly comments which do not contribute at all to the topic at hand? Must be very boring that Christmas of yours. On a more operational topic: even during Christmas (that Coca Cola induced commercialism party that gets attributed to some religion), people are using the Internet, and stuff breaks on the Internet, as such there will always be people who have to work on days like this. Greets, Jeroen

On Dec 21, 2007 6:48 AM, Joe Greco <jgreco@ns.sol.net> wrote:

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'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 :) -Chris

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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

I think we got here when "site-local" went away - we've effectively redefined link-local to mean "site-local," while using globally unique addressing.

site-local was replaced with ULA. Have you got your ULA yet? :-) ULA gives you /48's. 6to4 gives you /48's. Your customers already have /48's whether they know it or not (and some do). Mark

On Sun, 23 Dec 2007 19:46:26 +0100 Florian Weimer <fw@deneb.enyo.de> wrote:

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

Or possibly maybe Peter M. Gleitz's and Steven M. Bellovin's idea of "Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host" http://www.cs.columbia.edu/~smb/papers/tarp/tarp.html A /64 per host is probably not necessary, however if an end-site has a /48, that's 65K hosts so it wouldn't likely be much of a problem for most sites ... certainly not my house currently or in the forseeable future or my current employer, or most employers I've worked for in the past. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"

On Mon, 24 Dec 2007 09:58:44 +0900 Randy Bush <randy@psg.com> wrote:

...

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

and, with multiple addresses per interface, the home user surely _might_ need a /32.

What prompted you to suggest that? Trolling maybe?

might does not make right

Neither does being ridiculous.

randy

-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"