John, Thanks for the detailed reaction. Further comments below.
Le 31 mars 2010 à 19:38, John Jason Brzozowski a écrit : > I hope you do not mind, I have take the liberty to pull some text from your > original post [rd] No problem at all. > and will reply to them here: > > On 3/31/10 10:20 AM, "Rémi Després" <remi.desp...@free.fr> wrote: >> ... >> => If there are indeed OS bugs that break connectivity, they should justify >> quick patches like those that concern security. > [jjmb] anyone who has had to deal with releasing software can certainly > attest to the fact that these sort of fixes/enhancements may not occur in a > timely manner. [rd] Aren't security patches quickly dispatched? Wouldn't a modification of all recursive DNS servers be an even more difficult task? > There are things we need to be doing now to advance IPv6, > the ability to wait for a release is not always an option. I do agree that > the issues should be properly documented in fact, [rd] Yes. That's the key. > I fully expect to > contribute to the work and share data from my point of view. [rd] Agreeing on what is the proper behavior OF HOSTS is IMHO most urgent, for the remainder of the discussion to start on solid grounds. Observed broken IPv6 connectivities shouldn't exist between communicating hosts (clients and/or servers) that apply these NATURAL RULES: a) Send packets to an IPv6 public address only from a public IPv6 source address. Otherwise, the return path will be broken. b) Send IPv6 packets from a 6to4 address only to destinations that are also a 6to4 addresses. Otherwise, return paths may be inexistent. c) By default, send IPv6 packets that don't exceed the guaranteed PMTU in IPv6, i.e. 1280 octets. Otherwise, some packets may be systematically discarded on their way because of their size. (Note that TCP/IP stacks that can determine than larger PMTUs exist on some identified e2e paths, by PMTUD or otherwise, may send larger packets on these paths, but this is far more sophisticated, and can remain optional.) >> ... >> => As a minimum, what the problem really is should be documented before >> proposing to adopt any solution to solve it, in particular if it is "ugly". > [jjmb] some of us have been gathering data and have experiences that are > insightful. > I believe the intention here minimally is to document the same > so the community can review and comment. I do not believe there is a large > population of people that have attempted these sort of activities in scale, > I can assure that scale does matter. [rd] Agreed: scale does matter, and documenting observed facts is very precious. I look forward to what you have gathered. >> 3. >> "Only way of knowing the user has working IPv6 connectivity, is if the AAAA >> query came over IPv6!" >> => This DOESN'T WORK : >> - Today, dual-stack hosts on Free's network query Free's DNS in IPv4 (at the >> only DNS address they know, received in DHCPv4) >> - These hosts, because they have valid IPv6 addresses (i.e. have IPv6 >> enabled), ask for both As and AAAAs. >> - For maps.google.fr, for example, BOTH types of RRs are in the DNS. >> - They are included in DNS responses >> - Hosts then use IPv6 (preferred in case of choice). > [jjmb] it is not perfect but it is an indicator. The hosts on the Free > network are clearly not fully dual stack capable, > if they were the transport > could be used as an indicator of IPv6 reachability. [rd] - My host has OS X, which makes it IPv6 "capable". Since it gets a native IPv6 address (with the IPv6 prefix it receives from Free's CPE), it becomes IPv6 "enabled". As it also works in IPv4 as usual, it is AFAIKT fully dual stack. - Note that, so far, the dual-stack model keeps the DNS application layer independent from the IP layer, so that DNS servers may provide both As and AAAAs even if reached in IPv4. Changing this as would be a step backward. >> "Return 0 answers for AAAA if, and only if: - Query comes over Ipv4; - “A” >> record exists for same name; - DNSSEC is not used." >> => This hack would NOT ONLY be "ugly" (as acknowledged by their proponents), >> BUT ALSO would BREAK some of the IPv6 connectivities that are available today >> !!! > [jjmb] I do not see how this would break IPv6 connectivity. [rd] As I said, "dual-stack hosts on Free's network query Free's DNS in IPv4 (at the only DNS address they know, received in DHCPv4)". The DNS server returns available addresses, IPv4 and/or IPv6. This has worked satisfactorily for more than two years, and is used extensively, in particular to reach Google and IETF servers. If Free's DNS server would stop returning IPv6 addresses, as proposed in the hack being discussed, its dual-stack hosts would no longer reach Google and IETF in IPv6. > I can > tell you from first hand experience over the past several months there are > some enigmas here and that issues with 6to4 and other transition > technologies present challenges to readying infrastructure for real > broadband IPv6 traffic. [rd] Being a long time user of IPv6, and having at least enough knowledge of IPv6 to have designed 6rd, I will be glad, if I can, to help resolving these enigmas once they are identified. My guess is that the three natural rules above do resolve a number of them, if not all, but let us see. > And these challenges are likely not temporary. I > suggest deferring rejection until the issues, challenges, and documentation > have been documented. [rd] The proposed immediate rejection of the proposed hack is only because it would break some fully legitimate existing connectivities. But I do agree that, when more detailed facts are documented, we can look at the problem with fresh eyes, and see *which* hacks could be useful, and *where*. >> My strong reaction is only against this particular hack because: >> - it is based on the idea that OSes cannot be patched where they are bugged >> - it destroys legitimate connectivity for OSes that aren't bugged. > [jjmb] see my point above, do you really assume the turn around time here is > short? In any case, the earlier host-originated problems are identified, the earlier they are likely to be fixed (as they must be). Note that if an ISP (e.g. Comcast) implements the proposed hack only in its own recursive DNS, this is a choice IETF is not in a position to object to: it doesn't change anything for others. This will prevent some of the well behaved hosts of this ISP to actually use the IPv6 service, but no one else will be harmed. Regards, RD _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
