Fred, See my comments in line. I'm on travel, but should be able to do an update if necessary, after the LC ends.
Alexey, Thanks for the review. On 2011-06-07 05:16, Fred Baker wrote: > Thanks Alexey > > Brian, I would presume that the IESG will be looking for an update responsive > to these comments. > > On Jun 6, 2011, at 4:17 AM, Alexey Melnikov wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please >> resolve these comments along with any other Last Call comments you may >> receive. >> >> >> Document: draft-ietf-v6ops-6to4-advisory-01.txt >> Reviewer: Alexey Melnikov >> Review Date: 2011-06-06 >> IETF LC End Date: 2011-06-16 >> IESG Telechat date: >> >> >> >> Summary: ready (with nits) for publication as an Informational RFC. >> >> Major issues: none >> >> Minor issues: none >> >> Nits: >> >> 2.1. Router 6to4 >> >> Some 6to4 routers are also configured as "Relay routers." They >> behave as just described, but in addition they obtain native IPv6 >> connectivity with a normal IPv6 prefix. They announce an IPv6 route >> to 2002::/16. For example, assume that the 6to4 router at >> 190.0.2.187 is a relay router, whose address on the 6to4 side is >> 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: >> c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such >> as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 >> has its IPv6 default route set to 2002:c000:2bb::1, i.e. the relay. >> The packet will be delivered to the relay, encapsulated in IPv4. >> After decapsulation, the relay will forward the packet into native >> IPv6 for delivery. >> >> I might be getting confused, but is "the relay" in the last 2 quoted >> sentences mean 2 different things? No, it is the same relay - I can clarify that of course. >> When the remote host replies, the packet (source >> 2001:db8:123:456::321, destination 2002:c000:2aa::123) will find a >> route to 2002::/16 and hence be delivered to a 6to4 relay. The >> process will be reversed and the packet will be encapsulated and >> forwarded to the 6to4 router at 192.0.2.170 for final delivery. >> >> >> 3. Problems Observed >> >> 7. Bogus Address Failure: By design, 6to4 does not work and will not >> activate itself if the available V4ADDR is a private address >> [RFC1918]. However it will also not work if the available V4ADDR >> is a "bogon", i.e. a global address that is being used by the >> operator as a private address. A common case of this is a legacy >> wireless network using 1.1.1.0/24 as if it was a private address. >> In this case, 6to4 will assume it is connected to the global >> Internet, but there is certainly no working return path. >> >> This failure mode will also occur if an ISP is operating a >> Carrier Grade NAT between its customers and the Internet, and is >> >> I think adding a reference to an RFC that defines the term would be useful >> here. (I've seen the term with a proper reference recently, but I don't >> remember the name of the document.) I think at the moment it will have to be a work-in-progress reference (draft-ietf-behave-lsn-requirements) >> using global public address space as if it were private space to >> do so. >> >> 4.5. Content providers and their ISPs >> >> Content providers who do embed the relay function in this way could, >> in theory, accept inbound 6to4 traffic as well. This is highly >> unadvisable since, according the the rules of 6to4, they would then >> have to relay traffic for other IPv6 destinations too. So they >> should not be reachable via 192.88.99.1. Also, they should certainly >> not create an AAAA record for their 6to4 address - their inbound IPv6 >> access should be native, and advertising a 6to4 address might well >> lead to uRPF ingress filtering problems. >> >> What is uRPF? unicast reverse path forwarding (RPF) [RFC3704] I can add a reference. >> >> >> [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains >> via IPv4 Clouds", RFC 3056, February 2001. >> >> [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", >> RFC 3068, June 2001. >> >> I believe these 2 references need to be Normative, as they are required to >> understand this document. True, but this is an informational document, so why would any references be normative? Brian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
