[118491] in North American Network Operators' Group
Re: IPv6 Deployment for the LAN
daemon@ATHENA.MIT.EDU (James R. Cutler)
Thu Oct 22 15:23:15 2009
From: "James R. Cutler" <james.cutler@consultant.com>
In-Reply-To: <1256238211.4101.13.camel@shrike.home.ludost.net>
Date: Thu, 22 Oct 2009 15:22:11 -0400
To: Vasil Kolev <vasil@ludost.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:
> =D0=92 11:10 -0700 =D0=BD=D0=B0 22.10.2009 (=D1=87=D1=82), Owen DeLong =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>> OK... Here's the real requirement:
>>
>> Systems administrators who do not control routers need the ability in
>> a dynamic host configuration mechanism to
>> assign a number of parameters to the hosts they administer through
>> that dynamic configuration mechanism. These
>> parameters include, but, are not limited to:
>>
>> 1. Default Router
>> 2. DNS Resolver information
>> 3. Host can provide name to server so server can supply =
dynamic DNS
>> update
>> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case =
of =20
>> things
>> like Shim6, etc.)
>> 5. NTP servers
>> 6. Boot server
>> 7. Site specific attribute/value pairs (ala DHCPv4 Options)
>>
>> These assignments MUST be controlled by a server and not by the =20
>> router
>> because the router is outside of the
>> administrative control of the Systems Administrator responsible for
>> the hosts being configured.
>>
>
>
> And to add a real-world case for this - two months ago at HAR (hacking
> at random, a convention in the Netherlands) I was in the network team,
> handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
> connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and =20=
> at
> some point we asked the question around - ok, how should we provide =20=
> DNS
> and other useful information for the V6 only people?
>
> After a while with all the brains around, the decision was to write it
> on the datenklos through the field, where people can read it and
> configure it in their browsers. This would've been funny if it =20
> wasn't so
> sad.
>
> OTOH, for V4 everything with the DHCP worked fine (as it has always
> done, even at an event of this size), as is my experience with all the
> networks I've administered. Saying that DHCP doesn't work for me is
> extremely weird, as to me this means someone made specific effort to
> fuck it up.
>
> Finally - we have something that works, that's called DHCP. It might =20=
> not
> be perfect, it might have some weird issues and implementations, but
> it's actually making our lives easier, is tested and works. I'd love
> anything that would be better, but as an option, not as the only =20
> choice
> I have.
> And it's not just the protocol that I care about. I care about that =20=
> it's
> implemented in a HOST, where I can play with the software as much as
> possible, instead on a ROUTER, which is a vastly different device with
> rarely-updated OS, and even in the case where they're both the same
> machine(as in small office environments), they're again handled at
> different layers (kernel vs userspace).
> There are reasons that we're using what we're using, and not all of =20=
> them
> are "because we're masochistic idiots".
>
>
> --=20
> Regards,
> Vasil Kolev
Following on the comments above:
The security domain for HOST should not overlap the security domain =20
for ROUTER.
That is the primary driver of the separate administration of HOST and =20=
ROUTER. Heaven help us if the latest M$ virus, or even social-=20
engineering distributed malware began to affect BGP!
Give the router managers the NTP server addresses and their DHCP =20
forwarding list and leave them alone to produce a robust and reliable =20=
transport facility!
James R. Cutler
james.cutler@consultant.com
