Subject: Re: I-D Action: draft-ietf-6man-ra-pref64-05.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 1 Oct 2019 10:29:39 +0000

Hi:

Seconds is misspelled and 65536 should be 65535 (or perhaps 65528). 65536/8 = 8192 which is 0 when limited to 13-bits. Hence, you need to use 65528 (which is 8191 when divided by 8). And limit should be 8191, not 8192?

Lifetime 13-bit unsigned integer. The maximum time in units of 8
            secon[d]s over which this NAT64 prefix MAY be used. The value
            of Lifetime SHOULD by default be set to the lesser of 3 x
            MaxRtrAdvInterval divided by 8 or 8192 [8191]. The reciever MUST
            multiply the Lifetime value by 8 to calculate the maximum
            time in seconds the prefix MAY be used. Lifetime of 0
            indicates that the prefix SHOULD NOT be used anymore. Router
            vendors SHOULD allow adminstrators to specify non-zero
            lifetime values which are not divisible by 8. In such cases
            the router SHOULD round the provided value up to the lesser
            of nearest integer divisible by 8 or 65536[65528], divide the
            result by 8 and set the Lifetime field to the resulting
            value.

- Bernie

On Oct 1, 2019, at 12:58 AM, Jen Linkova <[email-masked]<mailto:[email-masked]>> wrote:

-05 version addresses the comments received from the chairs (thanks
Bob and Ole for the extensive review!).

Most important updates:
1) the option format changed:
   --- the length is always 2
   --- the Lifetime is 13 bits, so it should be multiplied by 8 to
get seconds (some clarification text added to specify what to do if
the value provided by an administrator can not be divided by 8)
  --- 3 bits are used to encode the prefix length
  --- no suffix support (intentional)
2) Multihoming section removed.

Thanks!

On Tue, Oct 1, 2019 at 2:52 PM <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

       Title           : Discovering PREF64 in Router Advertisements
       Authors         : Lorenzo Colitti
                         Jen Linkova
       Filename        : draft-ietf-6man-ra-pref64-05.txt
       Pages           : 10
       Date            : 2019-09-30

Abstract:
  This document specifies a Router Advertisement option to communicate
  NAT64 prefixes to clients.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-05
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ra-pref64-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ra-pref64-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 Oct 2019 13:14:38 +0200

>  PL       3-bit unsigned integer.This field encodes the NAT64 Prefix
>    (Prefix  Length. The PL field values 0,1,2,3,4 and 5 indicate the
>    Length)  NAT64 prefix length of 96,64,56,48,40 and 32 bits
>             respectively. The reciever MUST ignore the PREF64 option if
>             the prefix length field is not set to one of those values.

It is a little bit confusing, but maybe it's just me :-)

The 'PL field value' expands to 'Prefix Length field value'.  But value 
1 does not mean the bit length is 1, whereas I am used to understand 
Prefix Length as a number of bits.  Besides, it's an inverse 
correspondence: a small 0 corresponds to a big 96, and a big 5 
corresponds to a small 40.

My thinking would call it a 'Prefix kind' or 'Prefix color' field (I-D 
exists).  And instead of a reverse order, a straight order:

Prefix kind     Prefix length
     0         - 32
     1         - 40
     2         - 48
     3         - 56
     4         - 64
     5         - 96

Alex

Le 01/10/2019 à 06:57, Jen Linkova a écrit :
> On Tue, Oct 1, 2019 at 2:52 PM <[email-masked]> wrote:
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 Oct 2019 13:16:21 +0200

I want to ask you: how is the IID formed for an address with a plen 96?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Oct 2019 12:56:46 -0400

> The 'PL field value' expands to 'Prefix Length field value'.  But value 1
    > does not mean the bit length is 1, whereas I am used to understand Prefix
    > Length as a number of bits.  Besides, it's an inverse correspondence: a small
    > 0 corresponds to a big 96, and a big 5 corresponds to a small 40.

    > Prefix kind     Prefix length

So, if it is a table lookup, then that needs to be explicit.

If we have three bits, then we need to know what a receiver should do if it
sees 6 or 7.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Oct 2019 12:57:36 -0400

> I want to ask you: how is the IID formed for an address with a plen 96?

IIDs are not formed.
This is for combination with IPv4 from A records to form AAAA records.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 2 Oct 2019 08:58:20 +1000

> On 2 Oct 2019, at 2:56 am, Michael Richardson <[email-masked]> wrote:
> 
> 

See the text you quoted above.  "The reciever MUST ignore the PREF64 option if
the prefix length field is not set to one of those values."

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Wed, 2 Oct 2019 11:34:02 +1000

> Seconds is misspelled and 65536 should be 65535 (or perhaps 65528). 65536/8 = 8192 which is 0 when limited to 13-bits. Hence, you need to use 65528 (which is 8191 when divided by 8). And limit shou…

(facepalm) Indeed, thanks for pointing this out!
Will fix in -06.

> On Oct 1, 2019, at 12:58 AM, Jen Linkova <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 2 Oct 2019 11:36:09 +1000

On Tue, Oct 1, 2019 at 9:14 PM Alexandre Petrescu
<[email-masked]> wrote:
> exists).

Would 'Prefix Length Code' be better?

>And instead of a reverse order, a straight order:
>

As I'd expect that in the vast majority of cases the prefix length
will be /96, then IMHO it makes sense to map the most common use case
to '0' value.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 2 Oct 2019 11:39:18 +1000

> I want to ask you: how is the IID formed for an address with a plen 96?

Sorry, could you please elaborate? What IID?

Just to make sure we are on the same page:
- this draft is about sending NAT64 prefix to hosts.
- hosts do not use that prefix to form any IIDs, they use to to do
NAT64/DNS64 synthesis (as described in NAT64/DNS64 RFCs).

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Oct 2019 10:57:11 +0200

> Would 'Prefix Length Code' be better?

I guess yes.

> will be /96, then IMHO it makes sense to map the most common use case

It does indeed make sense to map the most common case to a distinctive 
number, and 0 is such a number.

And also to think how the programmer would implement.  Maybe the most 
common case is in an if(x) which is faster to write than if(!x).  But 
again it depends how the program is written.

Alex

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Oct 2019 11:06:17 +0200

Le 01/10/2019 à 18:57, Michael Richardson a écrit :
> IIDs are not formed. This is for combination with IPv4 from A records
> to form AAAA records.

So, the IID is formed starting from the IPv4 A record, I think.

(To explain myself - indeed an IID is a term typically used in a SLAAC
discussions: Host receives a prefix in RA, forms an IID from a random
seed, and appends it to the prefix thus issuing an address.  While here,
in pref64 context, the SLAAC is not run.

However, IID is also a term used in discussions involving simply an IPv6
address, even if it is not formed with SLAAC.  Some times the
requirements put on IID are completely independent of SLAAC use.  For
example, RFC4291 says "For all unicast addresses, except those that
start with the binary value 000, Interface IDs are required to [...]")

Alex

> 
> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Oct 2019 11:09:40 +0200

> Sorry, could you please elaborate? What IID?

Let me elaborate: by IID I meant the rightmost bits of an IPv6 address. 
The leftmost bits are the prefix of that address.

Any IPv6 address has an Interface ID, I think.

Do you think there are IPv6 addresses that dont have an Interface ID?

Alex

---

From: Jen Linkova <[email-masked]>
Date: Wed, 2 Oct 2019 21:44:35 +1000

> The leftmost bits are the prefix of that address.

In that case the process is described in
https://tools.ietf.org/html/rfc6052 (for translating packets from IPv4
to IPv6)
and https://tools.ietf.org/html/rfc6147 (for DNS synthesis).

> Do you think there are IPv6 addresses that dont have an Interface ID?

Hmm....I think it's a philosophical question but....yes. I do.
We can discuss an IID when an IPv6 address is assigned to an interface.
RFC4291 says:
"Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link.  They are required to be unique within a subnet
prefix.

Please note that in case of NAT64 the resulting IPv6 addresses
(produced from the NAT64 prefix) are not assigned to any interface. So
I do not think they contain any IID. For there is no interface
involved.

Indeed you can consider an IPv4 address encoded into IPv6 address to
be an IID - in such case I guess the answer to your question is simple
and described in
https://tools.ietf.org/html/rfc6052#section-2.2

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Oct 2019 14:05:02 +0200

Thanks for the pointers.  I will discuss these internally  with colleagues.

Le 02/10/2019 à 13:44, Jen Linkova a écrit :
[...]
> Hmm....I think it's a philosophical question but....yes. I do. We can
> discuss an IID when an IPv6 address is assigned to an interface.

I think you are right: an IID is part of an IPv6 address that is
assigned to an interface, because the first 'I' stands for Interface.

I wrongly assumed 'IID' in IPv6 to be the equivalent of 'Host part' in
IPv4.  There is no 'Host part' in IPv6.

[...]
> (produced from the NAT64 prefix) are not assigned to any interface.

This is good to know.

I guess I understand that an IPv6 address produced from the NAT64 prefix
is never assigned to any interface, be it real or logical or virtual
interface, be it simple NAT64 or NAT64 with 464XLAT or CLAT.

Alex

  So

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Oct 2019 14:59:21 +0200

Jen,

Excuses, as you can see I am discovering the entire NAT64 story if I can 
say so.  I know almost nothing about it, and I do not plan to implement 
at this time.

Why I am intrigued by it is because I have a high interest in the 64 
limit as you might know.  With colleagues we work in private on what 
might become one day become another Internet Draft on that topic.  I 
thought this 96 prefix is an aspect that relates to 64 limits, in a 
somehow encouraging manner.

There are many things in RFC4291 about IPv4-kinda IPv6 addresses that 
are worth considering for NAT64, and for 64 limits.

I do not want to stir waters, so I leave it there.

Alex