[97002] in North American Network Operators' Group
Re: NANOG 40 agenda posted
daemon@ATHENA.MIT.EDU (David W. Hankins)
Wed May 30 14:17:12 2007
Date: Wed, 30 May 2007 11:16:18 -0700
From: "David W. Hankins" <David_Hankins@isc.org>
To: nanog@nanog.org
In-Reply-To: <5BD9A2BA-6187-4C11-BDDA-502072823BB5@muada.com>
Errors-To: owner-nanog@merit.edu
--bjuZg6miEcdLYP6q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 29, 2007 at 02:06:54PM +0200, Iljitsch van Beijnum wrote:
> DHCPv6 can't provide a =20
> default gateway, you need stateless autoconfig for that even if you =20
> use DHCPv6 for address assignment.
I think you mean "router advertisement", not stateless autoconfig.
You don't need the M bit clear in order to use the router.
On this topic, DHCPv6 also can't deliver a subnet prefix to clients.
These are only delivered by router advertisements containing prefix
options (not all router advertisements will contain prefix options,
or may not include a prefix covering the allocated address), and
without them, DHCPv6 implementations are justified in assuming the
allocated address is a /128.
Logically, they can't talk to one another without an advertising
router present.
So...I think how these two protocols comingle could use some work.
In truth, I think we should just ditch rtadv/rtsol and add routers
and subnet-mask options to DHCPv6. That's a shorter path with more
finality than the pandora's box of adding options to rtadv.
> And there is the extra info, but DNS resolvers may be availalbe in =20
> stateless autoconfig in the future as well.
Again, you mean in rtadv. Is it just me, or does it seem unusual
for network infrastructure to advertise host configuration
parameters?
Maybe I'm getting old, but the idea of managing this configuration
information in my routers sounds like a real chore compared to the
old DHCP relayed central server model.
> This is probably the way we want to do IPv6 address provisioning for =20
> end-users in the future, but that requires that home gateways that =20
> implement IPv6 routing functionality come with the DHCPv6 prefix =20
> delegation client capability and have this configured by default so =20
> it all works out of the box.
There's also a bit of a hinky issue in routing the delegated prefix
to the client. Obviously, you don't trust route advertisements
=66rom the client - you're not going to run OSPF or BGP with all your
broadband customers.
How to "do this" in a way we can all just plug and play hasn't quite
been decided yet.
Would there be interest on a DHCPv6 related presentation at NANOG?
--=20
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
--bjuZg6miEcdLYP6q
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFGXb9ycXeLeWu2vmoRAhMUAJwPptXKXVv92Hr9UBtVA3EblA7NWACgk7Rv
QGWP7hml7mdgSz5PZvNDGXA=
=y7br
-----END PGP SIGNATURE-----
--bjuZg6miEcdLYP6q--
