turning on comcast v6
hardenrm at uchicago.edu
Tue Dec 31 21:56:59 UTC 2013
On Dec 31, 2013, at 2:16 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> Ryan Harden wrote:
>> 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
>> thinking is more important that yours. They're asking for it because they
>> 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
>> they're asking for the ability to manage their IPv6 systems the same way
>> do IPv4.
> 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.
> 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
> 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.
> 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.
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.
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'.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the NANOG