Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
RFC 6751

Note: This ballot was opened for revision 01 and is now closed.

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-06-19 for -01)
No email
send info
- I wondered if this was fully compatible with IPsec. Seems
like it ought to be but I've not thought it through, but maybe
the authors have. If so, that might be a good addition to
the security considerations. (And who knows, maybe doing
this experiment with btns might be a fun and even useful
thing to think about.)

- section 5, typo: s/piecesa/pieces/

(Brian Haberman) No Objection

Comment (2012-06-20 for -01)
No email
send info
I have no problems with the publication of this document, but I do have some technical issues that would be good to address in it.

1. Given the assumption that each network that is supporting 6a44 is using a /48, it would be good to state somewhere that operators who are allocated something smaller (e.g., /56) can't use this approach.

2. Does the 6a44 approach work correctly with RFC 3484 (or 3484bis) given that it is a prefix of last resort but is built out of an ISP's global prefix?

3. I do not understand why "Overall design simplicity" is considered an "Operational Requirement".

4. Section 4.4 mentions an applicability scenario where 6a44 applies when a dual-stack CPE is assigned only an IPv4 address.  If that is the case, what happens when the CPE is RFC 6204 (or 6204bis) compliant and supports 6rd or DS-Lite?  Does someone need to disable those features in the CPE?

5. Guidance should be given on what random method(s) should be used to generate the Bubble ID.

6. Section 6.4 (bullet 3) says 6a44 clients MUST limit the size of IPv6 packets they send to on-link destinations to the link MTU - 20.  What is meant by on-link in this case?  Any device inside the CPE should not be encapsulated.

7. Rule CT-2 states that protocol 41 encapsulation (direct to the IPv4 destination address) is used when sending to destinations within the same site. How does that rule relate to RR4-2 which seems to say that clients are still sending data to the relay via UDP?

(Russ Housley) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2012-06-19 for -01)
No email
send info
Changed to no object to follow the right process. Just learned something today about ISE and the datatracker. Sorry for the confusion. 

Nonetheless, those issues should be fixed before publication. 

Section 6.2., paragraph 3:

>    An IPv6 packet transmitted from a 6a44 client to another 6a44 client
>    of the same site is encapsulated in an IPv4 packet whose source and
>    destination addresses are the private-IPv4 addresses of the two
>    hosts.  The IPv4 packet is that of a complete datagram (its more-
>    fragment bit is set to 0, its offset is set to 0, and its datagram
>    identification may be set to 0).  The size of the IPv6 packet SHOULD
>    NOT exceed 1280 octets for off-link destinations, and MUST NOT exceed
>    the link MTU minus 20 octets for on-link destinations (see
>    Section 6.4).

  You reuse protocol type 41 but do not give any reference to rfc 2473.
  2473 lists a number of considerations in terms of ICMP error handling
  and also for the security of tunneling. 

Section 6.3., paragraph 1:

>    A Bubble is a UDP/IPv4 packet whose UDP payload comprises a "6a44-
>    client IPv6 prefix" field and a "Bubble ID" field, and whose UDP
>    checksum is set to 0.

  Why is the UDP checksum set to zero in this case? Is there
  any other protection against packet corruption? 
  There is no other means (as far as I can tell) in this case, it
  is thus required to have the UDP checksum set. Otherwise, the bubbles
  might carry wrong information back and forth. 

Section 6.4., paragraph 1:

>    Reassembly of a fragmented IPv4 datagram necessitates to remember its
>    identifier from reception of the first fragment to reception the last
>    one, and necessitates a timeout protection against packet losses.  If
>    such an IP-layer stateful processing would be necessary for 6a44, it
>    would make it more complex than needed, would introduce a
>    vulnerability to denial of service attacks, and would impose that all
>    fragments of a fragmented IPv4 datagram go to the same relay.  This
>    last point would be a constraint on how load balancing may be
>    performed between multiple 6a44 relays, and would therefore be
>    detrimental to scalability.

  First of all, fragmentation and de-fragmentation is performed
 by the IP layer in IPv4. This is the defined standard behavior which
 is not changed by this specificiation. This is not an argument for
 increased complexity or scalability. Please rewored to state that
 fragment is not desired, but remove the rest. 

Section 6.4., paragraph 2:

>    For 6a44 processing to remain completely stateless, IPv4 packets
>    containing encapsulated IPv6 packets must never be fragmented.  For
>    this:

  In your case you must mandate that the Don't Fragment (DF) bit in the
  IPv4 header is set, but you never state this!

  But your text isn't clear about this, as you write that always
  a complete UDP must arrive and that the IP packets have the 
  more fragments set to 0, but you do not specify anything about the
  do not fragement bit. I assume you try to talk about the latter one and
  not the more fragment bit. 

  How should the implementation react to ICMP error messages indicating
  that the packet is too big?

Section 6.5.1., paragraph 8:

>    TM-3  In the "Bubble sent" state, if the timer expires AND the
>          Attempt count is less than 4, then: the Attempt count is
>          increased by 1; a new bubble is sent with the current Bubble
>          ID; the "bubble sent" state is re-entered with the timer reset
>          to T1.

  It is better to say T1' = 2*T1. This will allow to back-off smoothly.

Section 6.3., page 14:

>    In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6
>    prefix" field is only reserved space for the response.  It is set to
>    0.  In a bubble from a 6a44 relay to a 6a44 client, it contains the
>    IPv6 prefix of the client.

 How are the values encoded on the wire. Please clarify this in the text.

Section 6.3., page 14:

>    In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field
>    contains a randomly chosen value, renewed in circumstances defined in
>    Section 6.5.1.  In a bubble from a 6a44 relay to a 6a44 client: if
>    the bubble is a response to a bubble received from the client, the
>    field contains the value found in the received bubble; if the bubble
>    is it is a reaction to a received IPv6/UDP/IPv4 packet whose IPv6 and
>    UDP/IPv4 sources are inconsistent, the field is set to 0.  The
>    purpose of this field is a protection against 6a44-relay spoofing
>    attacks (see Section 7).

 What means 'inconsistent' in technical terms here?

(Sean Turner) No Objection