Subject: Re: [DNSOP] FYI: DNSOPS presentation

From: [email-masked]
Date: Thu, 1 Apr 2010 08:37:05 +0000

On Wed, Mar 31, 2010 at 11:26:53PM -0700, Christopher Morrow wrote:
> On Wed, Mar 31, 2010 at 1:55 PM, Dan Wing <[email-masked]> wrote:
> 
> > But Remi's point is that those same systems (running Windows XP
> > and IE6) using 6rd will be denied the ability to access content
> > via IPv6.  Which removes an incentive for ISPs to add 6rd (and
> > offload the NAT44 they may soon have to install).
> 
> I'm not sure this is true:
> o the end-station sends a dns query to the ISP recursive resolver
> o the recursive resolver uses whichever protocol is 'best' for the
> lookup (assuming something like BIND's NS RTT caching happens in the
> majority of cases)
> o if the query goes over ipv6, is for a AAAA, a AAAA response could be returned
> o if the query goes over ipv4, is for a AAAA, no response is returned
> and presumably a follow-up A query happens.
> 
> Igor/Yahoo are proposing that recursive resolvers which have v6
> transport use it and be rewarded for doing so... if they have a
> longer/worse path over ipv6 there's a good chance the user experience
> will also suffer, so the users should use v4.

	but the ISP recursive resolver has no clue what the end-station
	(stub) is going to do with the result of the lookup. nor does
	if have any idea what proxies or forwarders are in the interviening
	path between it and the stub.

	it might look at the transport it received the query on (from the stub),
	cache that information, and then recursively ask the authoritative servers
	for the data (using whichever transport is "best" for the specific lookup
	to the authoritative server in question), then send the response back
	to the stub - weighting the response data based on the transport the
	stub asked the query on.

	regardless of how I (the stub) ask the recursive my question, (via IPv4,
	IPv6, DECNETPhaseV, NCP, bisync...) the recursive should give me what
	i ask for ... if i want AAAA answers then give me AAAA answers, even if
	you get the query over LU6.2.   Don't confuse DNS data with transport.

--bill

> 
> -chris
> 
> -chris
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andras Salamon <[email-masked]>
Date: Thu, 1 Apr 2010 12:11:12 +0100

On Wed, Mar 31, 2010 at 02:12:43PM -0700, Dan Wing wrote:
>There are two categories of ISP
>subscribers:
>
>    1. If subscriber is provisioned for IPv6, they are pointed at
>       the ISP's DNS server which responds to AAAA normally --
>    2. If subscriber is NOT provisioned for IPv6, they are
>       pointed at the ISP's DNS server which responds to AAAA
>       with an empty answer.

This proposal seems to have the right setup of defaults to work well
now and to continue working well as the IPv4/v6 landscape changes.

Moreover, as access to a recursive server is a _service_, I don't
see how one can stop ISPs from doing this.  DNS servers have never
presented a uniform namespace (due to propagation of changes and
later split DNS), though some ISPs respect the end-to-end principle
more than others.

On the downside I see this proposal moving us closer to a world
where messing about with DNS end-to-end service by the network is
seen as acceptable.

-- Andras Salamon                   [email-masked]

---

From: Andras Salamon <[email-masked]>
Date: Thu, 1 Apr 2010 13:42:40 +0100

On Thu, Apr 01, 2010 at 12:23:08AM -0400, John Jason Brzozowski wrote:
>Having advanced users (people like us) manually
>configure their DNS servers to point to HE (for example) will pertain to a
>small percentage of the overall Internet using population that must start
>using IPv6 without special configurations.

I thought DHCPv6 still supported lists of recursive DNS servers?
     http://www.faqs.org/rfcs/rfc3646.html

It would seem possible to set up a test "DNS4v4" recursive server,
serving an AAAA-free subset of DNS for v4 clients, and to test it
with an authentication server.  This would probably require diving
into the source code of one of the open source recursive resolver
implementations and disabling some of the AAAA code.  Or maybe paying
one of the DNS software vendors to add this feature.

Something like this would also help those customers whose OS insists
on trying to use IPv6 when an AAAA record is found via additional
records, even when there is no other indication that IPv6 is available.

Or are you arguing that ISPs are not going to deploy such hacks?

---

From: Rémi Després <[email-masked]>
Date: Thu, 1 Apr 2010 15:32:12 +0200

> offload the NAT44 they may soon have to install).

If I may, Dan, the fact that Free's native IPv6 is implemented with 6rd is not significant.
(Hosts don't know about it, and Free could switch to dual stack in all their routers without users being able to notice it.)

The important point is that Free offers native IPv6 to its customers in addition to IPv4, and that their DNS servers are both accessible in IPv4 AND capable to return AAAAs :
- Dual-satck hosts behind Free's CPEs get their DNS addresses as usual in IPv4.
- They query these DNS servers for both As and AAAAs.
- They use IPv6 when getting AAAA responses (with A responses or alone)

This has the great advantage to work without dual-stack hosts needing to acquire one or several IPv6 DNS addresses. (Means to acquire such addresses, such as DHCPv6 or RFC 5006, are not available in all hosts).

In my understanding, this has been key for IPv6 to be actually used as soon as Free's CPEs advertised IPv6 prefixes on its customer LANs. 

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 1 Apr 2010 16:07:43 +0200

Igor,

I have a feeling that the energy spent on defending *now* your proposed "solution" would better be spent providing asap details on the problem you are trying to solve, i.e. explaining which OS does what exactly, in which circumstances, to break what?

Le 31 mars 2010 à 23:19, Igor Gashinsky a écrit :

> This is *exactly* what I'm proposing -- all my presentation does is 
> document this as a feature and describes how it will work (the switch is 
> actually "disable-aaaa-on-v4-transport")... 

> .... the only question 
> is if you do this for all users, a subset of them, or none at all, and 
> that's going to be up to every individual ISP to do what is right for 
> them.. 

Right, each ISP is free to limit, in its own way, services it offers.
But the fact is that some dual-stack hosts that today reach Google in IPv6 on Free's network would not be able to do it on a network whose DNS does what you propose.

Regards,
RD

P.S.: Note that "disable-aaaa-on-v4-IP" would be more appropriate terminology than "disable-aaaa-on-v4-transport".
(UDP the transport layer used by the DNS is IPvX agnostic. IPv4/IPv6 is an IP matter, at the network layer.)

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Apr 2010 08:37:14 -0700

> -----Original Message-----
> From: John Jason Brzozowski 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 31, 2010 9:23 PM
> To: Dan Wing; Igor Gashinsky
> Cc: Andrew Sullivan; [email-masked]
> Subject: Re: [DNSOP] FYI: DNSOPS presentation
> 
> On 3/31/10 5:12 PM, "Dan Wing" <[email-masked]> wrote:
> 
> >> -----Original Message-----
> >> From: John Jason Brzozowski
> >> [mailto:[email-masked]]
> >> Sent: Wednesday, March 31, 2010 1:57 PM
> >> To: Igor Gashinsky; Dan Wing
> >> Cc: Andrew Sullivan; [email-masked]
> >> Subject: Re: [DNSOP] FYI: DNSOPS presentation
> >> 
> >> On 3/31/10 4:37 PM, "Igor Gashinsky" <[email-masked]> wrote:
> >> 
> >>> On Wed, 31 Mar 2010, Dan Wing wrote:
> >>> 
> >>> :: Users running IE6 today are IPv4-only users.  If/when they go
> >>> :: to IPv6, they will be running Windows 7 and whatever browser
> >>> :: is shipped by Microsoft.
> >> [jjmb] this is not what the Free people have indicated.  I
> >> think this is a
> >> flawed assumption.
> >>> 
> >>> Why do you say that? As far as I know, IE6 is an
> >> ipv6-capable browser,
> >>> as long as it's going to FQDN's.. So, what about IE6/XP users who
> >>> installed bittorent clients (or spyware/trojans) that
> >> enabled ipv6 for
> >>> them without the user knowing about it?
> >> [jjmb] Again from first hand experience, I can tell you there were
> >> unexpected non-trivial increase in P2P over IPv6 traffic.
> >>> 
> >>> :: It seems solvably operationally, by asking ISPs to point their
> >>> :: IPv4-only subscribers at an ISP-operated DNS server which
> >>> :: purposefully breaks AAAA responses (returns empty answer), and
> >>> :: to point their dual-stack subscribers at an ISP-operated DNS
> >>> :: server which functions normally.
> >> [jjmb] Solvable perhaps, however, there are operational
> >> impacts that are
> >> non-trivial.  Not to mention provisioning and in some 
> cases financial
> >> implications.
> >>> ::
> >>> :: Advanced IPv4-only users wanting to do AAAA queries (e.g.,
> >>> :: Teredo users, 6to4 users, etc.) should be sufficiently advanced
> >>> :: to point themselves at the ISP's normal nameserver or a
> >>> :: public DNS server on the Internet (e.g., Hurricane
> >>> :: Electric's, Google's, etc.).  That won't affect users running
> >>> :: uTorrent (which uses Teredo to provide IPv6 connectivity)
> >>> :: because it doesn't do AAAA queries to find peers.
> >> [jjmb] what percentage of broadband users fall into the
> >> advanced category
> >> and will that be adequate to facilitate IPv6 adoption.  I
> >> suspect no and
> >> this is not really an option in most cases for non-advanced users.
> > 
> > Sorry, it appears I was not clear.
> > 
> > I will describe it another way.  There are two categories of ISP
> > subscribers:
> > 
> >        this is the ISP's "normal" nameserver.  All is well.
> >        DNSSEC works, even if the validation is done by the client.
> >        No muss, no fuss.
> > 
> >        with an empty answer.  This helps with the transition
> >        without losing eyeballs.  DNSSEC breaks if the client
> >        queries AAAA and the client does DNSSEC validation.
> > 
> >        An advanced subscriber might be in this category (not
> >        provisioned for IPv6).  But that advanced user might want
> >        to query AAAA and get an answer.  That advanced user can
> >        use the ISP's "normal" DNS server, or Google's, or
> >        HE's, or opendns.org's, or whatever.  An advanced
> >        subscriber might want to do that to *purposefully*
> >        run Teredo, or to analyze a packet trace that
> >        includes IPv6 traffic (and do DNS reverse queries
> >        on the packet trace), get full results from the 'host'
> >        command, etc.
> > 
> > Clearer?
> > 
> > -d
> [jjmb] I see how you categorize things, the clarification 
> does not, however,
> change some of my points.  Having advanced users (people like 
> us) manually
> using IPv6 without special configurations.  The former 
> assumes there is a
> separate infrastructure in place with in the service 
> providers which, as
> mentioned earlier, has non-trivial challenges.

Yes, I heard that from you and Jason:  running another DNS
server costs the ISP money.  I understand nothing new comes
for free.

Content providers don't want to lose money (viewers), and
they currently seem reluctant to provide AAAA records to
ISPs.

An impasse.

I am trying to see how we might might provide Igor's 
requested functionality without breaking the DNS 
protocol.  That is -- how operationally we could achieve
the requested functionality.  This is the DNS ops list,
afterall.

-d

> > 
> >>> This is *exactly* what we are proposing -- the feature to
> >> return empty
> >>> answers would be needed for ipv4-only subscribers in order
> >> to keep them
> >>> ipv4-only. Also, if a fully ipv6-capable user visits that
> >> person's home,
> >>> the recursor would then be able to make the call on if they
> >> should pass
> >>> through AAAA to that particular user or not... I am by no
> >> means advocating
> >>> to make this behavior a default, just a feature.
> >>> 
> >>> Thanks
> >>> -igor
> >> =========================================
> >> John Jason Brzozowski
> >> Comcast Cable
> >> e) mailto:[email-masked]
> >> o) 609-377-6594
> >> m) 484-962-0060
> >> w) http://www.comcast6.net
> >> =========================================
> >> 
> > 
> 
> =========================================
> John Jason Brzozowski
> Comcast Cable
> e) mailto:[email-masked]
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =========================================
> 
>

---

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 01 Apr 2010 11:53:53 -0400

were it not Apr 1, I would think that was a typo.  Strangely enough, I 
actually worked on a protocol translator for LU6.2 devices on a BX.25 
(!) network, long ago in a galaxy far away...

I agree with your point, the medium in this case is not the 
message...apologies to Prof. McLuhan.  

On 4/1/2010 4:37 AM, [email-masked] wrote:
> 	if i want AAAA answers then give me AAAA answers, even if

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Apr 2010 09:51:16 -0400

Sorry for disappearing from this thread, but I was away.  I want to
draw attention to something in this discussion, however.

On Wed, Mar 31, 2010 at 03:25:35AM -0400, Igor Gashinsky wrote:
> 
> I will completely agree with you that this is where the problem *should* 
> be solved. However, we are about 5 years (if not more) too late in solving 
> it that way if we wanted to deploy ipv6 right now -- that is what we are 
> trying to address. Hell, IE6 still makes up close to 18% of all users out 
> there despite everybody trying to deprecate that browser, and the 
> percentage of ipv6 capable users is roughly the same as the percentage of 
> windows 98 users out there (0.3%)... So, given that clearly users don't 
> update their software often enough, it is too late to fix the applications 
> that are already deployed on users PCs (and their broken home 
> gateways/firewalls/etc), so, what do we do *right now*, to get those 
> "broken users" through the next 3-5 years till they upgrade? 

What that really says is that we failed to do this properly 5 years
ago, and instead shipped a lot of kludgey half-working stuff that was
sort of broken.  Having done that, in order to work around it, the
right answer now is to add a _new_ half-working kludge that will be
sort of broken, and to add it at central places in the network where
it will live effectively forever and where it will actually impede
perfectly legitimate users who are using dual stack.

I think that's a bad trade-off.  This is entirely a question of
trading the positive effects of doing something against the short- and
long-term costs of doing that thing.  I completely agree that there's
a serious problem here, and I don't buy for a second the argument that
end users need to experience this breakage in order to get them to
"upgrade" or "fix" or whatever their broken environments (we are past
the beginning of the automotive age, where every driver had to be able
to make emergency repairs at the side of the road).  But authority DNS
servers aren't in the right position in the network to figure out
whether the end user is having trouble: they can't even tell whether a
query that arrives at their door over v4 is due to an end host that is
using v4, given the existence of NAT-PT and the NAT64/DNS64 follow-on
currently proposed.  The ISP _might_ be able to do something, and even
has a customer-satisfaction incentive to try to find these broken
implementations and help the customer out.  The service itself might
be able to detect some things about what the client is actually able
to do.  But the DNS authority servers from the service operator are
just not in a position to draw any of those conclusions, and the
proposal can easily do as much harm as good.  Therefore, it shouldn't
be pursued.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.