v6 subnet size for DSL & leased line customers

Sun Dec 23 21:21:48 UTC 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/