Chairs review of <draft-ietf-6man-ra-pref64-04>

[Bob Hinden <[e-mail]>]

Jen, Lorenzo,

Our review is below.

Thanks,
Bob & Ole


> IPv6 Maintenance                                              L. Colitti
> Internet-Draft                                                J. Linkova
> Intended status: Standards Track                                  Google
> Expires: February 12, 2020                               August 11, 2019
> 
> 
>              Discovering PREF64 in Router Advertisements
>                      draft-ietf-6man-ra-pref64-04
> 
> Abstract
> 
>   This document specifies a Router Advertisement option to communicate
>   NAT64 prefixes to clients.
> 
> 

.  . . .

> 1.  Introduction
> 
>   NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism
>   to provide IPv4 access on IPv6-only networks.  In various scenarios,
>   the host must be aware of the NAT64 prefix in use by the network.
>   This document specifies a Router Advertisement [RFC4861] option to
>   communicate the NAT64 prefix to hosts.
> 
> 1.1.  Requirements Language
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> 1.2.  Terminology
> 
>   Pref64 (or NAT64 prefix): an IPv6 prefix used for IPv6 address
>   synthesis [RFC6146];

s/Pref64/PREF64/  here and elsewhere.  This would be consistent with title and headers.

> 
>   NAT64: Network Address and Protocol Translation from IPv6 Clients to
>   IPv4 Servers ([RFC6146]);
> 

“(  )” are not needed.  Here and later.


>   RA: Router Advertisement, a message used by IPv6 routers to advertise
>   their presence together with various link and Internet parameters
>   ([RFC4861]);
> 
> 

. . . .

> 
>   DNS64: a mechanism for synthesizing AAAA records from A records
>   ([RFC6147]);
> 
> 2.  Use cases for communicating the NAT64 prefix to hosts
> 
>   On networks employing NAT64, it is useful for hosts to know the NAT64
>   prefix for several reasons, including the following:
> 
>   o  Local DNSSEC validation.  As discussed in [RFC6147] section 2, the

s/validation/validation (DNS64 in sub-resolver mode)/

>      stub resolver in the host "will try to obtain (real) AAAA RRs, and
>      in case they are not available, the DNS64 function will synthesize
>      AAAA RRs for internal usage."  This is required in order to use
>      DNSSEC on a NAT64 network.
> 
>   o  IPv4 address literals on an IPv6-only host.  As described in
>      [RFC8305] section 7.1, IPv6-only hosts connecting to IPv4 address
>      literals can resolve the IPv4 literal to an IPv6 address.
> 
>   o  464XLAT [RFC6877]. 464XLAT is widely deployed and requires that
>      the host be aware of the NAT64 prefix.

s/464XLAT is widely deployed and requires/464XLAT requires/



>   o  Trusted DNS server.  AAAA synthesis is required for the host to be
>      able to use a DNS server not provided by the network (e.g., a DNS-
>      over-TLS server ([RFC7858]) with which the host has an existing
>      trust relationship).
> 
>   o  Networks with no DNS64 server.  Hosts that support AAAA synthesis
>      and that are aware of the NAT64 prefix in use do not need the
>      network to perform the DNS64 function at all.

Also, could the distinction be made clearer about which is to configure NAT64 and which to configure DNS64?

> 
> 3.  Why include the NAT64 prefix in Router Advertisements
> 
>   Fate sharing: NAT64 requires a routing to be configured.  IPv6

s/requires a routing/requires routing/

>   routing configuration requires receiving an IPv6 Router Advertisement
>   [RFC4861].  Compared to currently-deployed NAT64 prefix discovery
>   methods such as [RFC7050], including the NAT64 prefix in the Router
>   Advertisement minimizes the number of packets required to configure a
>   host.  This speeds up the process of connecting to a network that
>   supports NAT64/DNS64, and simplifies host implementation by removing
>   the possibility that the host can have an incomplete layer 3
>   configuration (e.g., IPv6 addresses and prefixes, but no NAT64
>   prefix).

Not everything is the above paragraph is about fate sharing.   Suggest splitting it for clarity.

> 
>   Updatability: it is possible to change the NAT64 prefix at any time,
>   because when it changes, it is possible to notify hosts by sending a
>   new Router Advertisement.
> 
> 

. . . .


> 
>   Deployability: all IPv6 hosts and networks are required to support

s/support/support Neighbor Discovery/

>   [RFC4861].  Other options such as [RFC7225] require implementing
>   other protocols.
> 

Such as?   Suggest listing them.

Suggest saying that it’s easier to deploy because it’s simpler to extend an existing ND implementation, than implementing and supporting a new protocol.


> 4.  Semantics

Would “Usage Guidelines” or “Discussion” be better than “Semantics”?  This doesn’t seem like
"semantics” to us.

> 
>   To support prefix lengths defined in ([RFC6052]) this option contains
>   the prefix length field.  However as /96 prefix is considered to be
>   the most common use case, the prefix length field is optional and
>   only presents for non-/96 prefixes.  It allows to keep the option
>   length to a minimum (16 bytes) for the most common case and increase
>   it to 20 bytes for non-/96 prefixes only (see Section 5 below for

Is 20 bytes correct?  Seems like 24 octets.

Also s/bytes/octets/

>   more details).

[See comment in Section 5]

> 
>   This option specifies exactly one NAT64 prefix for all IPv4
>   destinations.  If the network operator desires to route different
>   parts of the IPv4 address space to different NAT64 devices, this can
>   be accomplished by routing more specifics of the NAT64 prefix to
>   those devices.  For example, if the operator would like to route
>   10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space
>   through NAT64 device B, and the operator's NAT64 prefix is
>   2001:db8:a:b::/96, then the operator can route
>   2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B.
> 
>   This option may appear more than once in a Router Advertisement (e.g.
>   in case of graceful renumbering the network from one NAT64 prefix to
>   another).  Host behaviour with regards to synthesizing IPv6 addresses
>   from IPv4 addresses SHOULD follow the recommendations given in
>   Section 3 of [RFC7050], limited to the NAT64 prefixes that have non-
>   zero lifetime.
> 
>   In a network (or a provisioning domain) that provides both IPv4 and
>   NAT64, it may be desirable for certain IPv4 addresses not to be
>   translated.  An example might be private address ranges that are
>   local to the network/provisioning domain and should not be reached
>   through the NAT64.  This type of configuration cannot be conveyed to
>   hosts using this option, or through other NAT64 prefix provisioning
>   mechanisms such as [RFC7050] or [RFC7225].  This problem does not
>   apply in IPv6-only networks, because in such networks, the host does
>   not have an IPv4 address and cannot reach any IPv4 destinations
>   without the NAT64.  The multihoming and multiple provisioning domains
>   scenarios are discussed in Section 7.
> 
> 5.  Option format
> 
> 
> Colitti & Linkova       Expires February 12, 2020               [Page 4]
> Internet-Draft Discovering PREF64 in Router Advertisements   August 2019
> 
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |    Length     |           Lifetime            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     +                                                               +
>     |              Highest 96 bits of the Prefix                    |
>     +                                                               +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Lowest bits (96-127) of the prefix (optional, if Length > 2)  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Prefix Length |                  Reserved                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 


Would it be better to just use 8 bit prefix length and a 16 byte prefix field, like is done elsewhere in ND.  Why invent a new format?  This would simplify the format and be less complex.

> 
>                   Figure 1: NAT64 Prefix Option Format
> 
>   Fields:
> 
> 
> Colitti & Linkova       Expires February 12, 2020               [Page 5]
> Internet-Draft Discovering PREF64 in Router Advertisements   August 2019
> 
> 
>   Type     8-bit identifier of the Pref64 option type as assigned by
>            IANA: TBD
>   Length   8-bit unsigned integer.  The length of the option (including
>            the Type and Length fields) is in units of 8 octets. If the
>            prefix length is 96 bits the sender MUST set the Length to 2
>            and include the 96 bits of the prefix in the option. If the
>            prefix length is not 96 bits then the sender MUST set the
>            length to 3 and include all 128 bits of the prefix in the
>            Prefix field and set the Prefix Length field to the prefix
>            length.  The receiver MUST ignore the Pref64 option if the
>            length field value is 1. If the Length field value exceeds
>            3, the receiver MUST utilize the first 21 octets and ignore
>            the rest of the option.

Why not not ignore if Length > 3.  There are only two legitimate values, 2 and 3.


> 
>   Lifetime 16-bit unsigned integer.  The maximum time in seconds over
>            which this NAT64 prefix MAY be used. The value of Lifetime
>            SHOULD by default be set to lesser of  3 x MaxRtrAdvInterval
>            or 65535 seconds.  A value of zero means that the prefix
>            MUST no longer be used.
> 
>   Highest  96-bit unsigned integer. Contains bits 0 - 95 of the NAT64
>   96 bits  prefix.
>   of the
>   prefix
> 
> 
>   Lowest   32-bit unsigned integer. Contains bits 96 - 127 of the NAT64
>   bits of  prefix. This field is optional and presents only if the
>   the      prefix length is not 96 bits.
>   prefix

Perhaps add:  and the Length field is set to 3.


> 
>   Prefix   8-bit unsigned integer. Optional field which present only if
>   Length   the prefix length is not 96 bits. The sender MUST set it
>            only to one of the following values: 32, 40, 48, 56, 64
>            ([RFC6052]. The receiver MUST ignore the Pref64 option if
>            the prefix length value is not set to one of those numbers.
> 
>   Reserved A 3-byte unused field.  If present it MUST be initialized to
>            zero by the sender and MUST be ignored by the receiver. This
>            field is optional and presents only if the prefix length is
>            not 96 bits.
> 
> 6.  Handling Multiple NAT64 Prefixes
> 
>   In some cases a host may receive multiple NAT64 prefixes from
>   different sources.  Possible scenarios include (but are not limited
>   to):
> 
> 

. . . . .


> 
> 
>   Note that if the network provides Pref64 both via this RA option and
>   [RFC7225], hosts that receive the Pref64 via RA option may choose to
>   use it immediately before waiting for PCP to complete, and therefore
>   some traffic may not reflect any more detailed configuration provided
>   by PCP.
> 
> 7.  Multihoming

Is this section useful?  Could it be dropped.   Seems well beyond the scope of a new RA option.

> 
>   Like most IPv6 configuration information, the Pref64 option is
>   specific to the network on which it is received.  For example, a
>   Pref64 option received on a particular wireless network may not be
>   usable unless the traffic is also sourced on that network.
>   Similarly, a host connected to a cellular network that provides NAT64
>   generally cannot use that NAT64 for destinations reached through a
>   VPN tunnel that terminates outside that network.
> 
>   Thus, correct use of this option on a multihomed host generally
>   requires the host to support the concept of multiple Provisioning
>   Domains (PvD, a set of configuration information associated with a
>   network, [RFC7556]) and to be able to use these PvDs.
> 
> 

. . . . .



> 12.  References
> 
> 12.1.  Normative References
> 
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119,
>              DOI 10.17487/RFC2119, March 1997,
>              <https://www.rfc-editor.org/info/rfc2119>.
> 
>   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
>              DOI 10.17487/RFC4861, September 2007,
>              <https://www.rfc-editor.org/info/rfc4861>.
> 
>   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
>              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
>              DOI 10.17487/RFC6052, October 2010,
>              <https://www.rfc-editor.org/info/rfc6052>.
> 
> 12.2.  Informative References
> 
>   [I-D.ietf-intarea-provisioning-domains]
>              Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
>              Shao, "Discovering Provisioning Domain Names and Data",
>              draft-ietf-intarea-provisioning-domains-05 (work in
>              progress), June 2019.
> 
>   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
>              Rose, "DNS Security Introduction and Requirements",
>              RFC 4033, DOI 10.17487/RFC4033, March 2005,
>              <https://www.rfc-editor.org/info/rfc4033>.
> 
> 
> 
> 
> Colitti & Linkova       Expires February 12, 2020               [Page 9]
> Internet-Draft Discovering PREF64 in Router Advertisements   August 2019
> 
> 
>   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
>              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
>              DOI 10.17487/RFC6105, February 2011,
>              <https://www.rfc-editor.org/info/rfc6105>.
> 
>   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
>              NAT64: Network Address and Protocol Translation from IPv6
>              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
>              April 2011, <https://www.rfc-editor.org/info/rfc6146>.
> 
>   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
>              Beijnum, "DNS64: DNS Extensions for Network Address
>              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
>              DOI 10.17487/RFC6147, April 2011,
>              <https://www.rfc-editor.org/info/rfc6147>.
> 
>   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
>              Combination of Stateful and Stateless Translation",
>              RFC 6877, DOI 10.17487/RFC6877, April 2013,
>              <https://www.rfc-editor.org/info/rfc6877>.
> 
>   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
>              the IPv6 Prefix Used for IPv6 Address Synthesis",
>              RFC 7050, DOI 10.17487/RFC7050, November 2013,
>              <https://www.rfc-editor.org/info/rfc7050>.

Should this be normative?


> 
>   [RFC7225]  Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
>              Port Control Protocol (PCP)", RFC 7225,
>              DOI 10.17487/RFC7225, May 2014,
>              <https://www.rfc-editor.org/info/rfc7225>.
> 
>   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
>              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
>              <https://www.rfc-editor.org/info/rfc7556>.
> 
>   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
>              and P. Hoffman, "Specification for DNS over Transport
>              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
>              2016, <https://www.rfc-editor.org/info/rfc7858>.
> 
>   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
>              Better Connectivity Using Concurrency", RFC 8305,
>              DOI 10.17487/RFC8305, December 2017,
>              <https://www.rfc-editor.org/info/rfc8305>.
> 
> 
> 
> 

. . . .