[167918] in North American Network Operators' Group
Re: turning on comcast v6
daemon@ATHENA.MIT.EDU (James R Cutler)
Tue Dec 31 17:01:01 2013
From: James R Cutler <james.cutler@consultant.com>
In-Reply-To: <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu>
Date: Tue, 31 Dec 2013 15:59:57 -0600
To: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_52A55FED-2236-4EEC-B04A-56F5C9778F67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 31, 2013, at 12:11 PM, Ryan Harden <hardenrm@uchicago.edu> wrote:
> On Dec 31, 2013, at 1:10 AM, Timothy Morizot <tmorizot@gmail.com> =
wrote:
>=20
>> I've been in the process of rolling out IPv6 (again this night) =
across a
>> very large, highly conservative, and very bureaucratic enterprise. =
(Roughly
>> 100K employees. More than 600 distinct site. Yada. Yada.) I've had no
>> issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the =
IPv4
>> model. In fact, the IPv6 model has generally been much more =
straightforward
>> and easy to implement.
>>=20
>> So I'm a large enterprise operator, not an ISP. Convince me. Because =
I
>> don't see any need. And if I don't, I'm hard-pressed to see why the =
IETF
>> would.
>>=20
>> Scott
>=20
> I haven't seen anyone in this thread argue that DHCPv6+RA doesn't =
work. So we'd all expect that you'd do just fine deploying that way for =
your large enterprise. The point is that there are some (And based on =
the thread here and over at IPv6-OPS, not just a couple) operators who =
wish or are required to do things differently. I remember thinking how =
stupid it was we had to either statically configure or run DHCPv6 (which =
a lot of clients didn't support) for the sole purpose of handing out =
name servers, then we finally got around to RFC6106. There were lots of =
people who just couldn't understand why you'd ever want your router =
handing out name servers/dns search lists. Sure DHCPv6 was/is the =
'right' and 'clean' way to do it, but it shouldn't be required to make =
IPv6 functional. Clearly the IETF agreed, eventually.
>=20
> IMO, being able to hand out gateway information based on $criteria via =
DHCPv6 is a logical feature to ask for. Anyone asking for that isn't =
trying to tell you that RA is broken, that you're doing things wrong, or =
that their way of thinking is more important that yours. They're asking =
for it because they have a business need that would make their =
deployment of IPv6 easier. Which, IMO, should be the goal of these =
discussions. How do we make it so deploying IPv6 isn't a pain in the =
butt? No one is asking to change the world, they're asking for the =
ability to manage their IPv6 systems the same way they do IPv4.
>=20
> /Ryan
Please note that Ryan=92s =93manage their IPv6 systems=94 really means =
=93run their business=94. In many organizations the routing network is =
managed by a different group with different business goals and =
procedures than end systems. Allowing flexibility for this, if it is =
not overwhelmingly costly, is a reasonable goal.
On my part, I see adding a default route parameter to DHCPv6 about as =
earth shaking as adding a default NTP server list. In other words, cut =
the crap and do it so we can save NANOG electrons and get on with =
solving more important network problems.
--Apple-Mail=_52A55FED-2236-4EEC-B04A-56F5C9778F67
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlLDPl4ACgkQHzETiNcaVPnlOQCeKKQv4huws9dTcnq2rPF8eBPf
ELIAoPpOuSV52t0ZbVzNyuZ032Y4ff+o
=0Lm9
-----END PGP SIGNATURE-----
--Apple-Mail=_52A55FED-2236-4EEC-B04A-56F5C9778F67--
