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/
