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? > > 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.) > > 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? > > > [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. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
