Skip to main content

Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
draft-despres-6a44-02

Revision differences

Document history

Date Rev. By Action
2012-08-31
02 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-08-30
02 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-08-29
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-08-29
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-08-27
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-08-27
02 (System) IANA Action state changed to In Progress from Waiting on ADs
2012-08-20
02 (System) IANA Action state changed to Waiting on ADs from In Progress
2012-07-29
02 (System) IANA Action state changed to In Progress from Waiting on ADs
2012-07-16
02 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-07-11
02 (System) IANA Action state changed to Waiting on ADs from In Progress
2012-07-10
02 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-07-09
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-06-27
02 (System) IANA Action state changed to In Progress
2012-06-25
02 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-06-25
02 Amy Vezza IESG has approved the document
2012-06-25
02 Amy Vezza Closed "Approve" ballot
2012-06-25
02 Amy Vezza Ballot approval text was changed
2012-06-25
02 Amy Vezza Ballot approval text was generated
2012-06-25
02 Amy Vezza Ballot writeup was changed
2012-06-22
02 Rémi Després New version available: draft-despres-6a44-02.txt
2012-06-21
01 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation
2012-06-21
01 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-06-21
01 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-06-21
01 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-06-21
01 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-06-20
01 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-06-20
01 Brian Haberman
[Ballot comment]
I have no problems with the publication of this document, but I do have some technical issues that would be good to address …
[Ballot comment]
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?
2012-06-20
01 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-06-20
01 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-06-19
01 Stephen Farrell
[Ballot comment]

- I wondered if this was fully compatible with IPsec. Seems
like it ought to be but I've not thought it through, but …
[Ballot comment]

- 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/
2012-06-19
01 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-06-19
01 Martin Stiemerling
[Ballot comment]
Changed to no object to follow the right process. Just learned something today about ISE and the datatracker. Sorry for the confusion.

Nonetheless, …
[Ballot comment]
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?
2012-06-19
01 Martin Stiemerling [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss
2012-06-19
01 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-06-19
01 Martin Stiemerling
[Ballot discuss]

Section 6.2., paragraph 3:

>    An IPv6 packet transmitted from a 6a44 client to another 6a44 client
>    of the same …
[Ballot discuss]

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.
2012-06-19
01 Martin Stiemerling
[Ballot comment]
Section 6.3., page 14:

>    In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6
>    prefix" …
[Ballot comment]
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?
2012-06-19
01 Martin Stiemerling [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling
2012-06-18
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-06-18
01 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-06-16
01 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-06-12
01 Pearl Liang
Upon approval of this document, IANA would be requested to do two tasks.

First, IANA would assign 192.88.99.2 as the 6a44 IPv4 anycast address;
this …
Upon approval of this document, IANA would be requested to do two tasks.

First, IANA would assign 192.88.99.2 as the 6a44 IPv4 anycast address;
this would include making a note of this assignment in the IANA
IPv4 Address Space Registry located at:

www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

NOTE: IANA will work with the IESG as to the most appropriate place
for the assignment.

Second, IANA would assign a system port number in the Service Name and
Transport Protocol Port Number Registry for UDP only as follows:

Service Name: 6a44
Port Number: [ TBD ] - Authors suggest a value of 1009 Transport protocol: UDP
only
Description: IPv6 Behind NAT44 CPEs
Assignee: [IESG]
Contact: [IETF_Chair]
Reference: [ RFC-to-be ]

*NOTE* to Authors: please submit a template immediately for the UDP port
for 6a44 as per this document for Expert Review. The template is
available at the following link

http://www.iana.org/form/ports-services

These would be the only IANA actions required upon approval of this document.
2012-06-06
01 Ralph Droms Placed on agenda for telechat - 2012-06-21
2012-06-06
01 Ralph Droms State changed to IESG Evaluation from AD Evaluation
2012-06-06
01 Ralph Droms Ballot has been issued
2012-06-06
01 Ralph Droms Ballot approval text was generated
2012-06-06
01 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2012-06-06
01 Ralph Droms Ballot writeup was changed
2012-06-06
01 Ralph Droms Created "Approve" ballot
2012-05-17
01 Ralph Droms Ballot writeup was generated
2012-05-17
01 Ralph Droms Removed from agenda for telechat
2012-05-09
01 Ralph Droms Telechat date has been changed to 2012-05-24 from 2012-05-10
2012-05-09
01 Ralph Droms State changed to AD Evaluation from Publication Requested
2012-05-09
01 Ralph Droms Responsible AD changed to Ralph Droms from Russ Housley
2012-04-30
01 Cindy Morgan
The draft draft-despres-6a44-01
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The …
The draft draft-despres-6a44-01
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request:


This draft's abstract says:
In customer sites having IPv4-only CPEs, Teredo provides a last
resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However,
because it is designed to work without involvement of Internet
service providers, it has significant limitations (connectivity
between IPv6 native addresses and Teredo addresses is uncertain;
connectivity between Teredo addresses fails for some combinations of
NAT types). 6a44 is a complementary solution that, being base on ISP
cooperation, avoids these limitations. 6a44 uses specific prefixes
assigned by local ISPs (rather than the anycast address used by
Teredo, an evolution similar to that from 6to4 to 6rd). The
specification is complete enough for actual deployment, including
with independently written codes.

Its -00 version was reviewed for me by Dave Thaler, who pointed out
that it's not an extension of Teredo, instead it's a full replacement,
and should use a new port number. This change, along with other, more
editorial changes, have been made in the current (-01) version.


Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org
2012-04-30
01 Cindy Morgan Placed on agenda for telechat - 2012-05-10
2012-04-30
01 Cindy Morgan Note added 'ISE Submission'
2012-04-30
01 Cindy Morgan State Change Notice email list changed to brian.e.carpenter@gmail.com, dwing@cisco.com, shengjiang@huawei.com, despres.remi@laposte.net, draft-despres-6a44@tools.ietf.org, rfc-ise@rfc-editor.org
2012-04-30
01 Cindy Morgan Stream changed to ISE
2012-04-30
01 Cindy Morgan Intended Status changed to Experimental
2012-04-30
01 Cindy Morgan IESG process started in state Publication Requested
2012-04-30
01 (System) Earlier history may be found in the Comment Log for draft-despres-softwire-6a44
2012-04-23
01 Rémi Després New version available: draft-despres-6a44-01.txt
2012-01-07
00 (System) Document has expired
2011-07-06
00 (System) New version available: draft-despres-6a44-00.txt