Subject: Question for w.g. on <<draft-ietf-6man-ra-pref64-04>

From: Bob Hinden <[email-masked]>
Date: Mon, 9 Sep 2019 11:38:29 -0700

Hi,

From my reading of the list for <draft-ietf-6man-ra-pref64-04>, we have a choice between the format described in the draft:

     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                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format supports two lengths of the option (20 & 28 bytes) and allows for different NAT64 prefix lengths in the 28 byte version.

Based on the chairs comments and list discussion, the following format has been proposed:

     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          |  PL |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |              Highest 96 bits of the Prefix                    |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This allow for the ranges of prefix lengths (32, 40, 48, 56, 64) supported by NAT64 (RFC6052) and is 20 bytes long.

The merits of these formats has been discussed.

Please read the discussion and respond with your preference.  It would be good to hear from people who haven’t responded so far.

Thanks,
Bob

---

From: Erik Kline <[email-masked]>
Date: Mon, 9 Sep 2019 22:20:40 -0700

How about a 3rd/Nth format?  One whereby it's still possible to specify a
/96 but you don't have to include all the trailing zero-valued bytes?

My apologies if this has been raised already.

1st 8 bytes:  {
    uint8_t  type = IANA_TBD;
    uint8_t  len = 2 || 3;  /* octets */
    uint16_t  lifetime;  /* same as other lifetimes, no tinkering */

    uint8_t  prefix_len;  /* <= 96 */
    uint8_t  number_of_nonzero_prefix_bytes;  /* <= 12 */
    uint16_t  padding;  /* send: zero, recv: ignored */
}

prefix_len tells a client where to append the IPv4 address, and
number_of_nonzero_prefix_bytes tells the client when it can stop copying
prefix bytes out of this option.

2nd 8 bytes {
    uint32_t  s6_addr32_0;
    uint32_t  s6_addr32_1;
}

3rd 8 bytes /* if necessary */ {
    uint32_t  s6_addr32_2;
    uint32_t  padding;  /* send: zero, recv: ignored */
}

Note that with trivial effort we could also have some indication in the
first 8 bytes that the prefix is the WKP, and if so limit the option to
just 1 8-octet entry.

On Mon, 9 Sep 2019 at 11:38, Bob Hinden <[email-masked]> wrote:

> Hi,
>
> From my reading of the list for <draft-ietf-6man-ra-pref64-04>, we have a
> choice between the format described in the draft:
>
>      0                   1                   2                   3
> This format supports two lengths of the option (20 & 28 bytes) and allows
> for different NAT64 prefix lengths in the 28 byte version.
>
> Please read the discussion and respond with your preference.  It would be
> good to hear from people who haven’t responded so far.
>
> Thanks,
> Bob
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Sep 2019 13:28:52 +0200

Something like this?

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |!=0 prefixbytes|           Padding             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          s6_addr32_0                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          s6_addr32_1                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          s6_addr32_2                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Padding                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le 10/09/2019 à 07:20, Erik Kline a écrit :
> How about a 3rd/Nth format?  One whereby it's still possible to specify 
> a /96 but you don't have to include all the trailing zero-valued bytes?
> 
> On Mon, 9 Sep 2019 at 11:38, Bob Hinden <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>      From my reading of the list for <draft-ietf-6man-ra-pref64-04>, we
>     have a choice between the format described in the draft:
> 
>           0                   1                   2                   3
>     This format supports two lengths of the option (20 & 28 bytes) and
>     allows for different NAT64 prefix lengths in the 28 byte version.
> 
>     This allow for the ranges of prefix lengths (32, 40, 48, 56, 64)
>     supported by NAT64 (RFC6052) and is 20 bytes long.
> 
>     Please read the discussion and respond with your preference.  It
>     would be good to hear from people who haven’t responded so far.
> 
>     Thanks,
>     Bob
> 
> 
> 
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Sep 2019 13:30:19 +0200

>  From my reading of the list for <draft-ietf-6man-ra-pref64-04>, we have a choice between the format described in the draft:

I do not understand why the 8bit boundary and why the 32bit lower 64bit 
upper limits.  That is my oppinion.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Sep 2019 08:04:02 -0700

Alex,

> On Sep 10, 2019, at 4:30 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I do not understand why the 8bit boundary and why the 32bit lower 64bit upper limits.  That is my oppinion.

That how it is defined in RFC6052.   See Section 2 of RFC6052.

Bob

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Sep 2019 16:58:02 -0700

Actually, the non-zero prefix bytes is extraneous (I don't know what I was
thinking).  Just the length of the option is sufficient to say how many
non-zero (and possibly some zero-valued) bytes needed to be encoded.

And if length=1 (meaning 8 bytes) then it can be assumed that the
RFC6052#section-2.1 WKP is in use.  :D

On Tue, 10 Sep 2019 at 08:04, Bob Hinden <[email-masked]> wrote:

> >> From my reading of the list for <draft-ietf-6man-ra-pref64-04>, we have
> a choice between the format described in the draft:
> >>      0                   1                   2                   3

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Sep 2019 10:55:01 +0200

> That how it is defined in RFC6052.   See Section 2 of RFC6052.

Thank you for the pointer.  It says that the plen can only be like that: 
32, 40, etc.  It can't be 33, for example.

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Sep 2019 10:52:30 -0400

Jen & Lorenzo

I tried to dive into the thread as best I could and have a bunch of
excerpts and questions and comments below in RED.

With the new packet format being proposed I see that the 4 byte optional
field for non /96 scenario's was removed as we are thinking to close the
door on any other prefix length option.  Is that correct or am I reading
that wrong?

There was a lot discussed in the thread and it was confusing to follow
along...

Original from draft -04  - NAT64 Prefix Option Format

 0                   1                   2                   3

New format Bob mentioned - NAT64 Prefix Option Format

 0                   1                   2                   3

>From draft -04 trying to account for all possible use cases if customers
use the well known /96 length and other possible lengths defined in RFC
6052.
    **draft 04 top of page 3 section 4**

   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

   more details).

   L=1 - no prefix present

   L=2 /96 -most common use case

   L=3 Non /96 prefixes

   L>3 Non /96 prefixes   ===> From the thread questions about RA packet to
big and fragmentation issue - and fragmentation EH not supported with RA
being an issue  - we would not support >3

! From Ole on Sept 9th 1:07am
 Now you have 3(1) different implementations out there:
 1) Those that don't support this option
 2) Those that only support 96 bits prefix length (l=2)
 3) Those that support arbitrary prefix length (l=2, l=3)
 4) Those that support some new options (l>3)
>
> You could merge 2+3 into one with a different packet format.======> It
looks we are chose this new packet format

I'm not sure I understand. If an implementation decides to support
only /96 Pref64 it has very little to do with the option format.
I suspect we might (and probably will) have implementations supporting
/96 only even if we decide to waste RA bits and  always include the
prefix length field.

>And drop 4 by not allowing extensions.============> However the packet
format looks like it dropped the prefix options field for non /96 prefix
lengths

I do not have a strong opinion re: extension, I was thinking that
allowing extension does not have any disadvantages and might be
beneficial later. If you believe L > 3 introduces issues we can drop
this.

I think just as with transition technology tunneling methods such as teredo
we have a well known address 2001::/32 and then have the ipv4 translated
ipv6 address with bits 96-127 containing the embedded IPv4 address what if
we eliminated as Bob may have accidentally noted in the packet format if we
closed the door on other prefix lengths ad only allowed for the well known
/96 which would be the most common use case.  There has been alot of back
and forth on the trade off of on the prefix lengths to be supported and
having to support all possible permutations.

 I am good with just supporting the most common use case of the well known
/96 but from and implementation standpoint folks want to have options as it
exists today with NAT64 RFC6146 It sounds like we have to support all
options so I don't think we have any choice but to support all options.

How do you plan for interoperability if you allow for implementations only
supporting /96 and for extensions?  I don't think we can do just /96
How is the network operator going to deal the number of mutations of host
implementations?
 - hosts only supporting /96
 - hosts supporting extension A, B or Z
 - hosts not supporting Pref64, but 7050
 - hosts supporting only PCP
 - hosts supporting only DHCP option =>dhcpv6 stateful

RFC 6052

2.2 <https://tools.ietf.org/html/rfc6052#section-2.2>.  IPv4-Embedded
IPv6 Address Format

   IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses
   follow the same format, described here as the IPv4-embedded IPv6
   address Format.  IPv4-embedded IPv6 addresses are composed of a
   variable-length prefix, the embedded IPv4 address, and a variable-
   length suffix, as presented in the following diagram, in which PL
   designates the prefix length:

    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |32|     prefix    |v4(32)         | u | suffix                    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |40|     prefix        |v4(24)     | u |(8)| suffix                |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |48|     prefix            |v4(16) | u | (16)  | suffix            |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |64|     prefix                    | u |   v4(32)      | suffix    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |96|     prefix                                    |    v4(32)
|*=========> Are we only supporting this option??*
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                                 Figure 1

   In these addresses, the prefix shall be either the "Well-Known
   Prefix" or a "Network-Specific Prefix" unique to the organization
   deploying the address translators.  The prefixes can only have one of
   the following lengths: 32, 40, 48, 56, 64, or 96.  (The Well-Known
   Prefix is 96 bits long, and can only be used in the last form of the
   table.)

***From Lorenzo response to Jen at 2:08am***

On Mon, Sep 9, 2019 at 2:05 PM Jen Linkova <[email-masked]> wrote:

> I'm not sure I understand. If an implementation decides to support
> only /96 Pref64 it has very little to do with the option format.
> I suspect we might (and probably will) have implementations supporting
> /96 only even if we decide to waste RA bits and  always include the
> prefix length field.================> Agreed - No sense wasting the
> precious RA bits given that they will more then likely never be used
>

Absolutely. Supporting non-/96 in a host is much more complex than just
parsing this option. Many implementations (including, at least, Android)
support only /96 today, even though RFC 7050 allows discovering
different prefix lengths. Also, it depends on what deployments those
devices are targeting. I am only aware of one network that does not use /96
today.==============> I am good with ditching the 32 bit prefix length
field as well if that is what we decide

**Length & Lifetime field discussion***

from draft -04

Lifetime    16-bit unsigned integer.  The maximum time in seconds
over======> Are we thinking of splitting this field into 13 bits & 3
bit length field so that the RA packet does not get fragmented
            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.

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.

*So by splitting the lifetime 16 bit field into two fields a 13 bit
lifetime & 3 bit length field we can ditch the 32 bit prefix length field
and still support all the "non /96" RFC 6052 pref64 lenghts * *****Excerpts
from the discussion on length & lifetime*****

Lorenzo Colitti <lorenzo=[email-masked]>
Sep 9, 2019, 2:18 AM (2 days ago)
to Jen, 6man, draft-ietf-6man-ra-pref64, Bob, N,
On Mon, Sep 9, 2019 at 3:08 PM Jen Linkova <[email-masked]>
wrote:=============>This
thread is a bit confusing - are we thinking of splitting 16 bit lifetime
into 13 bit and using the remaining 3 bits for prefix length options -8
permutations

> Yes, my fault, copy-n-paste w/o doing the math ;)
> 13 bit. Still not 16 bits. So all cons apply:
> - not all lifetime values can be encoded (I'm aware of deployments
> where router lifetime and MaxRtrAdvInterval/MinRtrAdvInterval are set
> to quite low values);
> - it makes the protocol and the troubleshooting unnecessary complicated.
> etc
>

"Not all lifetime values can be encoded" means that the lifetime of the
NAT64 prefix will sometimes be different than the ones of the other fields
in the RA, and thus expire at different times, which is bad. That said,
often-used lifetimes such as x hours, x days, etc. are divisible by 8 so
perhaps this is not too bad. n*10 minutes is not divisible by 8 but n*20
minutes and n*30 minutes are.

> > At some point it might be worth having a discussion of the use and value
> of lifetimes in these options...
>
> Lifetimes are *very* useful. One of the key benefit is to be able to
> notify hosts about changes. I need to be able to deprecate the prefix
> (and other configuration parameters) and propagate the changes to
> hosts.
> Yes, I'm doing it *often* and I do not expect that need to disappear
> any time soon.
>

Absolutely. In networking, things change all the time. If the network
cannot inform the host that something has changed, then the only
alternative left is that the network pretends that something didn't change
with things like NAT and VRRP.
Jen,

> Lifetimes are *very* useful. One of the key benefit is to be able to===============>
I agree the lifetime is very useful of how long the prefix is valid verses
stale also helps to deprecate prefix - change prefix64
> notify hosts about changes. I need to be able to deprecate the prefix
> (and other configuration parameters) and propagate the changes to
> hosts.
> Yes, I'm doing it *often* and I do not expect that need to disappear
> any time soon.

Yes, but are you actually adhering to the lifetime?
The lifetime as used in RA can be thought of as a promise by the network.
This service (address or whatever) is promised to be valid for at least
this amount of time. I expect what you do is to break that promise. E.g
state, sure Ms Host the NAT64 prefix is valid for the next 7 hours, then
turn around 30 seconds later and state, gee, btw, it's now invalid. And if
that's the use of this, perhaps a more explicit mechanism would be better.
Ref. flash renumbering of address prefixes. Anyway, I think this is a
larger discussion outside of the scope of pref64.

Cheers,
Ole > On Sat, Sep 7, 2019 at 12:59 AM Bob Hinden <[email-masked]>
wrote:
>>>     |     Type      |    Length     |  Lifetime      |  Prefix len  |
>>> And prefix length could even be 3 bits.
>>>
>>> An 8-bit lifetime is not enough, though: it should be at least as long
as the RA lifetime. Basically you have 1 type, 1 length, 2 lifetime, 12
prefix and that's 16 bytes, the maximum for len=2. Anything else puts you
at len=3.
>>>
>>> I proposed assigning 3-bits to the prefix length and 5-bits to the
lifetime (on receipt it would be mulitplied by 8), but my co-author was so
mercilessly opposed to it that I don't think we ever presented it to the WG
:-)
>>
>> I like that approach (that is, 3-bit prefix length field) given that
RFC6052 limits the prefix length to a limited set of values (32, 40, 48,
56, 64) so it easy to encode.   The resulting format and processing would
be much simpler.
>
> 3-bits prefix length is not a problem. What scares me is  5-bits
> lifetime (so the actual lifetime would be calculated by  multiplying
> the filed value by 8).
> IMHO it's quite far from being 'simpler to process’.

Well it would be 13-bits of lifetime if 3-bits for prefix length where used
as
lifetime + prefix len is 16-bits.  To get the same range for lifetimes as
other
options multiply by 8 (read in bits 16..31 as a network short, covert to
host order
and &= ~0x7 to get the lifetime.

        lifetime = ntohs(bits16to32) & ~0x7;

        unsigned char table[8] = { 32, 40, 48, 56, 64, 96, 0, 0 };
        prefixlen = table[ntohs(bits16to32) & 0x7];
        if (prefixlen == 0) goto err;

        or

        unsigned char table[8] = { 32, 40, 48, 56, 64, 96, 0, 0 };
        lifetime = ntohs(bits16to32);
        prefixlen = table[lifetime & 0x7];
        lifetime &= ~0x7;
        if (prefixlen == 0) goto err;
Actually it is trivial to implement.  See above. Thank you

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

---

From: Jen Linkova <[email-masked]>
Date: Thu, 12 Sep 2019 10:13:31 +1000

Hi Gyan,

Sorry for the top quoting but I found it difficult to respond inline w/o
messing up the formatting.
To answer you main question: *all* proposed formats do support non-96
prefixes (all possible prefix lengths allowed by RFC6052).
The choice is between the format currently described in the draft and the
format when the prefix length is encoded in 3 bits and the lifetime is
encoded in 13 bits.

I'm not sure I could conclude from your email which one would you support?

Thanks!

On Thu, Sep 12, 2019 at 12:52 AM Gyan Mishra <[email-masked]> wrote:

>    L>3 Non /96 prefixes   ===> From the thread questions about RA packet
> to big and fragmentation issue - and fragmentation EH not supported with RA
> I think just as with transition technology tunneling methods such as
> teredo we have a well known address 2001::/32 and then have the ipv4
> translated ipv6 address with bits 96-127 containing the embedded IPv4
> address what if we eliminated as Bob may have accidentally noted in the
> packet format if we closed the door on other prefix lengths ad only allowed
> for the well known /96 which would be the most common use case.  There has
> been alot of back and forth on the trade off of on the prefix lengths to be
> supported and having to support all possible permutations.
>
> 2.2 <https://tools.ietf.org/html/rfc6052#section-2.2>.  IPv4-Embedded IPv6 Address Format
>
>     |96|     prefix                                    |    v4(32)     |*=========> Are we only supporting this option??*
> Lifetime    16-bit unsigned integer.  The maximum time in seconds over======> Are we thinking of splitting this field into 13 bits & 3 bit length field so that the RA packet does not get fragmented
> On Mon, Sep 9, 2019 at 3:08 PM Jen Linkova <[email-masked]> wrote:=============>This
>> > At some point it might be worth having a discussion of the use and
>> value of lifetimes in these options...
>>
> Well it would be 13-bits of lifetime if 3-bits for prefix length where
> used as
>> Actually, the non-zero prefix bytes is extraneous (I don't know what I
>> was thinking).  Just the length of the option is sufficient to say how many

-- 
SY, Jen Linkova aka Furry

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 11 Sep 2019 22:01:01 -0400

Sent from my iPhone

> On Sep 11, 2019, at 8:13 PM, Jen Linkova <[email-masked]> wrote:
> 
> Hi Gyan,
> 
> Sorry for the top quoting but I found it difficult to respond inline w/o messing up the formatting.
> To answer you main question: *all* proposed formats do support non-96 prefixes (all possible prefix lengths allowed by RFC6052).
> The choice is between the format currently described in the draft and the format when the prefix length is encoded in 3 bits and the lifetime is encoded in 13 bits.
> 

With the proposed format to save on packet length to avoid fragmentation and to support all RFC 6052 prefix lengths we are dropping the 
the 4 byte prefix length and borrowing 3 bits from the lifetime field dropping it to 13 bits to encode up to 8
prefix lengths which is more then enough encoding to cover all lengths.

Please correct me if I mis stated anything.

I support the new proposed format as it makes sense and I think loosing 3 bits of lifetime makes it pretty low but not horrible
as 13 bits would give 8192 seconds (2.5 hours) versus 16 bits 65535 seconds (18 hours) The slaac prefix valid lifetime default is 30 days
and preferred lifetime 7 days defaults.  I think for nat64 prefix64 it’s ok as the prefix will go stale faster but still even 18 hours is not that long.

One last question I had is on the 4 byte prefix option which contains the 
IPv4 address that would be embedded per RFC6052 that is being removed - does that not 
have to be present for DNS64 IPv6 RR synthesis to occur for “non /96” prefix 
lengths.

Thank you 

Gyan

>> I tried to dive into the thread as best I could and have a bunch of excerpts and questions and comments below in RED.
>> 
>> With the new packet format being proposed I see that the 4 byte optional field for non /96 scenario's was removed as we are thinking to close the door on any other prefix length option.  Is that correct or am I reading that wrong?
>> 
>> There was a lot discussed in the thread and it was confusing to follow along...
>> 
>> From draft -04 trying to account for all possible use cases if customers use the well known /96 length and other possible lengths defined in RFC 6052.
>>    L>3 Non /96 prefixes   ===> From the thread questions about RA packet to big and fragmentation issue - and fragmentation EH not supported with RA being an issue  - we would not support >3
>> 
>> > You could merge 2+3 into one with a different packet format.======> It looks we are chose this new packet format
>> 
>> >And drop 4 by not allowing extensions.============> However the packet format looks like it dropped the prefix options field for non /96 prefix lengths
>> 
>> I think just as with transition technology tunneling methods such as teredo we have a well known address 2001::/32 and then have the ipv4 translated ipv6 address with bits 96-127 containing the embedded IPv4 address what if we eliminated as Bob may have accidentally noted in the packet format if we closed the door on other prefix lengths ad only allowed for the well known /96 which would be the most common use case.  There has been alot of back and forth on the trade off of on the prefix lengths to be supported and having to support all possible permutations. 
>> 
>>  I am good with just supporting the most common use case of the well known /96 but from and implementation standpoint folks want to have options as it exists today with NAT64 RFC6146 It sounds like we have to support all options so I don't think we have any choice but to support all options.
>> 
>> How do you plan for interoperability if you allow for implementations only supporting /96 and for extensions?  I don't think we can do just /96 
>> How is the network operator going to deal the number of mutations of host implementations?
>> 2.2.  IPv4-Embedded IPv6 Address Format
>> 
>>     |96|     prefix                                    |    v4(32)     |=========> Are we only supporting this option??
>>> prefix length field.================> Agreed - No sense wasting the precious RA bits given that they will more then likely never be used
>> 
>> Absolutely. Supporting non-/96 in a host is much more complex than just parsing this option. Many implementations (including, at least, Android) support only /96 today, even though RFC 7050 allows discovering different prefix lengths. Also, it depends on what deployments those devices are targeting. I am only aware of one network that does not use /96 today.==============> I am good with ditching the 32 bit prefix length field as well if that is what we decide
>> 
>> So by splitting the lifetime 16 bit field into two fields a 13 bit lifetime & 3 bit length field we can ditch the 32 bit prefix length field and still support all the "non /96" RFC 6052 pref64 lenghts 
>> 
>> ****Excerpts from the discussion on length & lifetime****
>> 
>> On Mon, Sep 9, 2019 at 3:08 PM Jen Linkova <[email-masked]> wrote:=============>This thread is a bit confusing - are we thinking of splitting 16 bit lifetime into 13 bit and using the remaining 3 bits for prefix length options -8 permutations
>> "Not all lifetime values can be encoded" means that the lifetime of the NAT64 prefix will sometimes be different than the ones of the other fields in the RA, and thus expire at different times, which is bad. That said, often-used lifetimes such as x hours, x days, etc. are divisible by 8 so perhaps this is not too bad. n*10 minutes is not divisible by 8 but n*20 minutes and n*30 minutes are.
>>  
>>> > At some point it might be worth having a discussion of the use and value of lifetimes in these options...
>>> 
>> Absolutely. In networking, things change all the time. If the network cannot inform the host that something has changed, then the only alternative left is that the network pretends that something didn't change with things like NAT and VRRP.
>> 
>> Jen,
>> 
>> > Lifetimes are *very* useful. One of the key benefit is to be able to===============> I agree the lifetime is very useful of how long the prefix is valid verses stale also helps to deprecate prefix - change prefix64 
>> The lifetime as used in RA can be thought of as a promise by the network. This service (address or whatever) is promised to be valid for at least this amount of time. I expect what you do is to break that promise. E.g state, sure Ms Host the NAT64 prefix is valid for the next 7 hours, then turn around 30 seconds later and state, gee, btw, it's now invalid. And if that's the use of this, perhaps a more explicit mechanism would be better. Ref. flash renumbering of address prefixes. Anyway, I think this is a larger discussion outside of the scope of pref64.
>> 
>> Cheers,
>> Ole
>> 
>> 
>> > On Sat, Sep 7, 2019 at 12:59 AM Bob Hinden <[email-masked]> wrote:
>> >>>      0                   1                   2                   3
>> >>> An 8-bit lifetime is not enough, though: it should be at least as long as the RA lifetime. Basically you have 1 type, 1 length, 2 lifetime, 12 prefix and that's 16 bytes, the maximum for len=2. Anything else puts you at len=3.
>> >>> 
>> >>> I proposed assigning 3-bits to the prefix length and 5-bits to the lifetime (on receipt it would be mulitplied by 8), but my co-author was so mercilessly opposed to it that I don't think we ever presented it to the WG :-)
>> >> 
>> >> I like that approach (that is, 3-bit prefix length field) given that RFC6052 limits the prefix length to a limited set of values (32, 40, 48, 56, 64) so it easy to encode.   The resulting format and processing would be much simpler.
>> > 
>> Well it would be 13-bits of lifetime if 3-bits for prefix length where used as
>> lifetime + prefix len is 16-bits.  To get the same range for lifetimes as other
>> options multiply by 8 (read in bits 16..31 as a network short, covert to host order
>> Actually it is trivial to implement.  See above.
>> 
>> 
>> Thank you
>> 
>> Gyan S. Mishra
>>> On Tue, Sep 10, 2019 at 7:58 PM Erik Kline <ek=[email-masked]> wrote:
>>> Actually, the non-zero prefix bytes is extraneous (I don't know what I was thinking).  Just the length of the option is sufficient to say how many non-zero (and possibly some zero-valued) bytes needed to be encoded.
>>> 
>>> And if length=1 (meaning 8 bytes) then it can be assumed that the RFC6052#section-2.1 WKP is in use.  :D
>>>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 12 Sep 2019 15:28:31 +1000

On Thu, Sep 12, 2019 at 12:01 PM Gyan Mishra <[email-masked]> wrote:
> as 13 bits would give 8192 seconds (2.5 hours) versus 16 bits 65535 seconds (18 hours)
>The slaac prefix valid lifetime default is 30 days

I believe the proposal was to calculate the actual lifetime by
multiplying the Lifetime field value by 8, not having the shorter
lifetime.The reason is:
the prefix lifetime should not be shorter than the router lifetime,
otherwise it's possible for the prefix to expire before the next RA
arrives.

> have to be present for DNS64 IPv6 RR synthesis to occur for “non /96” prefix

If I understand you correctly you are saying that with the new
proposed format we can not specify the suffix? Actually it's a very
good question and that's exactly why the format we have in the draft
still has all 128 bits - in case we need the suffix.

Currently the suffix is expected to be 0 but RFC6052 says
 'These bits are reserved for future extensions
   and SHOULD be set to zero.  Address translators who receive IPv4-
   embedded IPv6 addresses where these bits are not zero SHOULD ignore
   the bits' value and proceed as if the bits' value were zero.  (Future
   extensions may specify a different behavior.)'.

Good question - so the benefit of the format in the draft is that we
can encode the suffix if needed (in addition to better representation
of the lifetime).
Ole, Bob, what do you think?
There is no case for non-zero suffix now but shall we assume that it's
not going to change, esp. providing RFC6052 allows that?

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Sep 2019 09:12:28 +0200

Hi Jen,

> not going to change, esp. providing RFC6052 allows that?

The only use case 6052 presents for suffix is subsumed by MAP.
You would also enter into the same problems you have with multiple option formats. You would end up with interoperability problems. Some hosts on the links supports the new suffix definition and some don't.

And you would have to somehow signal what this new mechanism using suffix actually was...

I think you have two options here, either you do this as a "service announcement" or you do it as configuration. In the former you have to make darn sure that both sides are in agreement of what the "service definition" is. In the latter case the host can present what it supports/expects and the network can offer a suitable service to the best of its ability. That we typically do with DHCP.

Cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Sep 2019 09:29:02 -0700

Jen,

> On Sep 11, 2019, at 10:28 PM, Jen Linkova <[email-masked]> wrote:
> 

Seems to me that to start using non-zero suffixs several IETF specifications and, of course, many implementations would have to change.   There would need to be a strategy for how to deploy it given the resulting mixed implementations.   Doing a “bis” of this specification would be the easy part.

I lean to not doing anything now, seems unlikely to happen to me.

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Sep 2019 23:32:50 -0400

Jen

I am good with the proposed format which gives flexibility for current and
future implementations then implementing the suffix now and better
representation of lifetime.  So I agree to not doing anything now since
"non /96" use cases are unlikely.  Since many implementations exist with
nat64 w/ /96 all 0s suffix that adding the non zero suffix now would be
complicated as existing implementations and resulting interoperability
issues with a variety of mixed options formats  and as Bob mentioned
changing the specification would be the easier then all the options
permutations of resulting implementations.

Thank you

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

On Thu, Sep 12, 2019 at 12:29 PM Bob Hinden <[email-masked]> wrote:

> >> I support the new proposed format as it makes sense and I think loosing
> 3 bits of lifetime makes it pretty low but not horrible
> >> and preferred lifetime 7 days defaults.  I think for nat64 prefix64
> it’s ok as the prefix will go stale faster but still even 18 hours is not
> that long.
> >
> Seems to me that to start using non-zero suffixs several IETF
> specifications and, of course, many implementations would have to change.
>  There would need to be a strategy for how to deploy it given the resulting
> mixed implementations.   Doing a “bis” of this specification would be the
> easy part.
>

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347