Subject: [Gen-art] Gen-ART LC review of draft-ietf-v6ops-6to4-advisory-01

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Jun 2011 12:17:42 +0100

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.

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jun 2011 10:16:13 -0700

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 might be getting confused, but is "the relay" in the last 2 quoted sentences mean 2 different things?
> 
> 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 believe these 2 references need to be Normative, as they are required to understand this document.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jun 2011 11:38:37 +1200

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.

>> 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.

>> 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)

>>   lead to uRPF ingress filtering problems.

unicast reverse path forwarding (RPF) [RFC3704]

I can add a reference.
>> 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

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jun 2011 16:57:52 -0700

> True, but this is an informational document, so why would any references be normative?

This is something we spoke about in the working group, and you answered me the same way. I think he's not saying (and I was not saying then) that the references are normative for the Internet. They're saying that, unlike an informative reference (which may give you a deeper understanding but for most of the document are optional reading), you can't understand this document if you don't understand those two.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jun 2011 14:28:09 +1200

> This is something we spoke about in the working group, and you answered me the same way. I think he's not saying (and I was not saying then) that the references are normative for the Internet. They…

Correct, but (process weanie hat on) I don't see anything in the discussion of rules
for references in RFC 2026 that requires any such consideration in non-standards track
documents. I don't want to change this unless directed by the IESG.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jun 2011 19:54:38 -0700

> documents. I don't want to change this unless directed by the IESG.

OK, we'll wait for Russ' usual "discuss" saying "do what he said".

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Jun 2011 11:09:55 +0100

>This is something we spoke about in the working group, and you answered me the same way. I think he's not saying (and I was not saying then) that the references are normative for the Internet. They'…
Correct. And that is the definition of a Normative reference.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Jun 2011 11:10:02 +0100

>documents. I don't want to change this unless directed by the IESG.
This is not covered by RFC 2026, it is covered by the IESG statement on 
Normative/Informative references 
<http://www.ietf.org/iesg/statement/normative-informative.html>, which 
reads:

Within an RFC, references to other documents fall into two general 
categories: "normative" and "informative". Normative references specify 
documents that must be read to understand or implement the technology in 
the new RFC, or whose technology must be present for the technology in 
the new RFC to work. An informative reference is not normative; rather, 
it only provides additional information. For example, an informative 
reference might provide background or historical information. 
Informative references are not required to implement the technology in 
the RFC.

[...]

Note 3: The normative/informative distinction is relevant in any 
document that amounts to a technical specification, even if its intended 
status is Experimental or Informational.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jun 2011 02:20:19 +1200

On 2011-06-07 22:10, Alexey Melnikov wrote:
>>> This is something we spoke about in the working group, and you
>>> answered me the same way. I think he's not saying (and I was not
>>> saying then) that the references are normative for the Internet.
>>> They're saying that, unlike an informative reference (which may give
>>> you a deeper understanding but for most of the document are optional
>>> reading), you can't understand this document if you don't understand
>>> those two.
>>>   
>>

Dang! You know, I almost remember drafting that Note myself ;-)

Sure, of course I will do what the ADs tell me.

   Brian