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
