[167917] in North American Network Operators' Group
Re: turning on comcast v6
daemon@ATHENA.MIT.EDU (Ryan Harden)
Tue Dec 31 16:57:24 2013
From: Ryan Harden <hardenrm@uchicago.edu>
To: Tony Hain <alh-ietf@tndh.net>
Date: Tue, 31 Dec 2013 21:56:59 +0000
In-Reply-To: <044c01cf0665$22fa8260$68ef8720$@tndh.net>
Cc: North American Network Operators'
Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_FBBB58AD-A141-4629-A99A-C29DA5C12131
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 31, 2013, at 2:16 PM, Tony Hain <alh-ietf@tndh.net> wrote:
> Ryan Harden wrote:
> ...
>>=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
> As I said in the response to Leo, this issue has been raised before =
and
> couldn't get traction because the combination of a one-size-fits-all =
mantra
> from the leadership with concession such that the dhcp model would be
> self-contained, would have led to the end of the RA model. You are =
correct,
> neither way is better, and both need to operate independently or in
> combination, but getting there requires a clear use case, or many =
similar
> cases, to make progress.=20
>=20
> I believe you are correct in that many people do use the dhcp option =
to
> assign the router, but quantifying that is a very difficult task =
because
> that community rarely worries about driving standards to get their =
way. I
> find that most of this community finds innovative ways to reuse tools
> defined for a different purpose, but its close enough to accomplish =
the task
> at hand while avoiding the cost of getting a vendor to build something
> specific. That is all fine until the original backer of the tool goes =
a
> different direction, and ongoing evolution requires someone to justify =
its
> continued support. The scattered community has so many different =
corner-case
> uses it is hard to make a clear and quantified need for what the tool =
should
> become.=20
>=20
> The primary reason that this is even a discussion is that the decision =
was
> made long ago in the DHCP WG to avoid bringing forward unused baggage =
from
> the evolution of IPv4 and dhcp by not bringing any options forward =
until
> someone documented an ongoing use for it. That remains the only real
> requirement I am aware of for getting a dhcp option copied forward =
from IPv4
> to IPv6; document a widespread use case. This one has had an =
artificial
> requirement of getting past the dhcp vs. RA model wars, but that would =
have
> been, and still is easy enough to beat down with sufficiently =
documented
> use. Documented use is where things fail, because we loop back to the =
point
> about the people using it don't participate in driving the process to
> demonstrate how widespread the use actually is, and what specific
> functionality is being used to make sure the new definition is =
sufficient.=20
>=20
> Lee asked the question about use cases, and you were the only one that
> offered one with substance. Compound that with the point that nobody =
else
> jumped in with a 'me too', and the case could be made that you are =
looking
> for a standard to be defined around your local deployment choices. Not =
to
> say your deployment is isolated, wrong, or shouldn't be considered
> best-practice, rather that it is hard to demonstrate consensus from a =
single
> voice. Besides documenting the use case, it will help to fight off
> objections by also documenting why this innovative use is deployed =
rather
> than another widely deployed choice (in the case you present, why not
> 802.1X?, not that it is better, just 'why not' ; and I personally =
consider
> pre-dated or inconsistent implementations at deployment as a perfect
> justification, but that is just my take). At the end of the day, if
> operators don't actively participate in the standards process, the =
outcome
> will not match their expectations.=20
>=20
> Tony
>=20
>=20
>=20
Couple things=85
It should be noted that I don't intend to use DHCPv6 to hand out gateway =
information. I expect DHCPv6+RA to continue to fulfill my needs. So any =
notion that I'm trying push anything to meet any local deployment =
choices can be stopped right there. However, I can understand that some =
places might and do want to deploy things in the scenario I outlined =
previously. Some would love to deploy IPv6 but are hamstrung by old =
processes or tools with stupid assumptions or dependencies. Are the =
processes stupid? yes, Should they be replaced? absolutely. Is =
explaining that you need to rebuild your processes and tools to support =
this IPv6 thing that a very small percentage of your customers have even =
heard of, let alone asked for easy or likely to get approved? no.=20
I think you are absolutely correct in that the people who are stuck =
deploying with these scenarios don't participate in the standards =
process or even know where to start with getting their voice heard. I =
jumped into this conversation not because I have anything to lose or =
gain from it, but because I noticed the quick and deliberate efforts to =
brush it aside. There's the "you're doing it wrong" crowd and the "We =
already squashed this ten times" crowd. Neither of which are =
constructive. People (yes most network engineers are people) don't take =
very well to simply being told they're doing it wrong with the only =
suggestion of fixing it being to redesign everything they do. And =
perhaps if the subject keeps getting brought up, the user base =
requesting such a feature isn't as small as the "we've already squashed =
this" crowd would like us to believe.
I'm frustrated by this whole thing because I only jumped in to provide a =
hypothetical use case in response to those asking for one. Aside from a =
few, most quickly responded with "Here's an example of why my network =
doesn't do that, therefore your use case is invalid" and "sucks to be =
you, If I were you I'd just not deploy that way". Most (not all) of the =
opponents already have their minds made up on this matter. No use case =
will be good enough and no number of requests will be enough to consider =
it. Perhaps many network operators don't participate in the standards =
process because they can read the archives and see that most ideas that =
don't fit the status quo are met with severe opposition by the same =
handful of people that seem to push everyone else around in their =
particular area of 'expertise'.=20
I'm happy that this particular issue isn't affecting the deployment of =
IPv6 here. But if I move on to another job or inherit a network with =
these constraints, I'd be very happy to have this option as a =
transitional phase until I could get IPv6 deployed in _my_ ideal way =
with DHCPv6+RA and tools to match.
/Ryan
--Apple-Mail=_FBBB58AD-A141-4629-A99A-C29DA5C12131
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-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlLDPaoACgkQtuPckBBbXbo8lQCfTw+RD/iFuCFoZwgVx97SkHFG
OKUAn00DTm431N4yt01X2BiyVhB0PuYV
=59sY
-----END PGP SIGNATURE-----
--Apple-Mail=_FBBB58AD-A141-4629-A99A-C29DA5C12131--
