[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New (-02) version of IPv6 CPE Router draft is available for review
Le mercredi 23 juillet 2008 18:31:08 EricLKlein@softhome.net, vous avez
> Alain Durand writes:
> >> The problem with addressing this problem with a service discovery
> >> protocol is that it will not meet the requirement of what to do when the
> >> router is the only service and is in need of initial configuration. In
> >> the past Cisco mandated that the console port was the way to do this
> >> while others have gone for a direct connect USB, but in a wireless
> >> situation there is no physical port to connect to while configuring the
> >> CPE.
> >> So unless you want to replace a "well known IP address" with a "well
> >> known ULA" then we need to find another solution. Or are you proposing
> >> that we make the discovery protocol enable a "find and configure
> >> CPE/router" option? If so I have a problem with the security
> >> implications of such a wide open configuration requirement.
> > Eric,
> > From a security perspective, what is the difference between:
> > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a
> > similar range, asking people to configure it using http://[10.0.0.1]
> > B) the same thing using link local address, with the router being
> > configured using fe80::1 and asking people to configure it using
> > http://[fe80::1] C) the same replacing link local by ULA
> Your example B is exactly what I am suggesting, a it is identical to A in
> an IPV6 world.
As already pointed out in this same thread, link-local addresses do NOT work
in most web browsers, as you need to know which local interface to use - not
suited at all within a for-dummies installation guide.
ULAs will not fit the bill either because the prefix ought to be
pseudo-random, and different for each and every shipped box.
GUAs do not fit as they also depend on the customer, and by definition, are
not available until the CPE has been successfully configured.
Site-local addresses would have worked, but they're now deprecated.
Multicast service discovery does not work because it is not implemented with
current hosts - if we specify if now, it will be years before it can be used.
So... you're stuck instructing the customer to use the constant IPv4 address.
That works today and will continue to work for the foreseeable future of
dual-stack hosts on unmanaged networks.
As much as I believe the CPE ought to provision a permament ULA prefix, I also
believe the initial configuration argument is completely bogus.