ebersman> It's a nice thought. But considering how little we've
ebersman> converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs
ebersman> static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't
ebersman> even start on how many IPv6 transition techs there are), any
ebersman> consensus on "better" is going to be a fascinating trick.
TLemon> This is not an accurate representation of the situation. There
TLemon> are some people who see DHCPv6 versus SLAAC as an ideological
TLemon> problem rather than a choice between features, but this is
TLemon> completely orthogonal to the DNS issue.
Sorry. Unclear analogy. Not conflating v6 and DNS, just pointing out
that reaching consensus when we have non-compatible operational views
and requirements tends to not lead to a solution in any real time frame.
Proponents of SLAAC vs DHCPv6 tend to have different pain points and
biases based on how they run their networks and we aren't likely to come
to a meeting of the minds any time soon due to those differing needs.
Not saying either network design is wrong or bad either. Just saying
that different needs means we won't get a "one size fits all" solution.
TLemon> There is real work going on on the DNS problem, and while it's
TLemon> not clear everyone will want to deploy a nice solution, I don't
TLemon> think there's any serious argument within the IETF that such a
TLemon> solution should not be deployed, nor is there serious contention
TLemon> over how to do it (although there are several options). I don't
TLemon> _think_ there are any ideological disputes; the question is
TLemon> simply which solution is best for any particular use case. And,
TLemon> of course, actually getting the documents done that describe the
TLemon> several different ways of approaching the problem.
I'd agree that we all would like the option of a "nice" use of PTRs. It
does seem like there are two sets of conflicting pain points for which
it's not clear to me there is a compromise in what we're talking about
in this draft.
The two groups with obvious pain points are:
- service providers who want a way to avoid breaking things for
customers while not being operationally complicated/insane
- mail/spam folks who seem to be saying that the current v4 method is
a time bomb that will explode any minute, is unmaintainable and
doing v6 the same way is untenable to them
Doing autogen'd PTRs in v6 violates the anti-spam folks' needs. Not
having any PTR at all for consumers potentially violates the ISP needs.
Things I don't know that anyone knows for sure but make it hard to reach
consensus on a solution:
- what are the various interesting/crazy/insane uses PTRs in v4 now
(beyond the mail req of forward/reverse existing and matching),
i.e. what will break now and in the future if there are no v6 PTRs
for consumer IPs if content providers do the same uses in v6
- how much is the current v4 autogen being done by ISPs truly breaking
mail/spam, how/when/how-soon will it explode and how much additional
stress/breakage would doing v6 autogen add
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
