North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: v6 subnet size for DSL & leased line customers

  • From: Iljitsch van Beijnum
  • Date: Sun Dec 23 16:24:15 2007


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/