Subject: Re: [v6ops] transition-ipv4aas-01: 464XLAT and NAT

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 16:49:13 +0200

Hi Barbara,

It is following section 6.3 of RFC6877 (464XLAT).

It is true that RFC8273 is much more recent, and obviously it was not considered, but in a quick consideration I think it is a very complex scenario, if you're using DHCPv6-PD to also use RFC8273 ...

It may be possible, but I'm not completely sure if you are thinking in some specific scenario that I don't see right now?

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Fecha: miércoles, 6 de junio de 2018, 16:44
Para: 'JORDI PALET MARTINEZ' <[email-masked]>, "[email-masked] list" <[email-masked]>
Asunto: transition-ipv4aas-01: 464XLAT and NAT

    I see:
         464XLAT-1:  The IPv6 Transition CE Router MUST perform IPv4 Network
                   Address Translation (NAT) on IPv4 traffic translated
                   using the CLAT, unless a dedicated /64 prefix has been
                   acquired using DHCPv6-PD [RFC3633] (IPv6 Prefix Options
                   for DHCPv6).
    and am curious why the dedicated /64 prefix exclusion applies only to a prefix acquired by IA_PD, and not one acquired by RFC 8273? 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Jun 2018 15:43:39 +0000

> From: JORDI PALET MARTINEZ <[email-masked]>
> Hi Barbara,
> 
> It is true that RFC8273 is much more recent, and obviously it was not
> considered, but in a quick consideration I think it is a very complex scenario, if
> you're using DHCPv6-PD to also use RFC8273 ...
> 
> It may be possible, but I'm not completely sure if you are thinking in some
> specific scenario that I don't see right now?

Section 6.3 of RFC 6877 is clearly requiring multiple /64 prefixes, which RFC 8273 cannot deliver. But Section 6.3 is also making it clear that it is really about *having* the multiple /64 prefixes (including a dedicated /64 for the translation), and not how the prefixes are acquired (though it does, unfortunately, include the phrase "When a dedicated /64 prefix is not available for translation from DHCPv6-PD", it seems to me from the previous sentences that the intent is for there to be a dedicated /64 and the authors weren't thinking about the possibility of other means for prefix acquisition. It shouldn't matter how the prefixes are acquired. The current 464XLAT-1 suggests that it does matter how the prefix is acquired. The 464XLAT-1 language says if a dedicated prefix were acquired by manual provisioning or some other future mechanism, that would not be sufficient to avoid NAT44. Only a /64 acquired by IA_PD can avoid NAT44. 

That seems bizarre to me, so I'd really like someone to explain this better to me, why prefix acquisition method matters. Simply pointing to RFC 6877 is insufficient, because that provides no justification for why only acquisition via IA_PD is acceptable. If method doesn't matter, then "using DHCPv6-PD [RFC3633] (IPv6 Prefix Options for DHCPv6)" should be deleted from the end of the requirement. 
Barbara
 
>     and am curious why the dedicated /64 prefix exclusion applies only to a
> prefix acquired by IA_PD, and not one acquired by RFC 8273?
> 
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.consulintel.es&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=WpmF5aM67Cksj61TnYwI1GrsTlwCQ14tm1lafnTU88A&
> s=FakBFjJ2Kjbgeua8eYDE6MaGnAShhoOn4DGWgXh7mAc&e=
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be considered a
> criminal offense. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original sender to
> inform about this communication and delete it.
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 18:07:50 +0200

I guess the point is that whatever is the mechanism you use to provision the /64 prefixes, the CE need to make sure to use it only for the CLAT, but anyway that's out of our scope ... it is something for the RFC6877.

I see two choices:

1) Make it an example

          464XLAT-1:  The IPv6 Transition CE Router MUST perform IPv4 Network
                    Address Translation (NAT) on IPv4 traffic translated
                    using the CLAT, unless a dedicated /64 prefix has been
                    acquired, for example as indicated in Section 6.3 of RFC6877,
                    using DHCPv6-PD [RFC3633] (IPv6 Prefix Options for DHCPv6).

2) Remove it

                    acquired.

I think the example in choice 1, make sense to match the RFC6877 text, but I'm fine either way.

Regards,
Jordi

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Jun 2018 14:44:05 +0000

I see: