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

[Gyan Mishra <[e-mail]>]

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

New format Bob mentioned - NAT64 Prefix Option Format

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

>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 <[e-mail]> 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=[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
wrote:
>>>      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 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: [phone]

Email: [e-mail]

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



On Tue, Sep 10, 2019 at 7:58 PM Erik Kline <ek=[e-mail]>
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
>
> On Tue, 10 Sep 2019 at 08:04, Bob Hinden <[e-mail]> wrote:
>
>> Alex,
>>
>> > On Sep 10, 2019, at 4:30 AM, Alexandre Petrescu <
>> [e-mail]> wrote:
>> >
>> >
>> >
>> > Le 09/09/2019 à 20:38, Bob Hinden a écrit :
>> >> 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.
>> >
>> > 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
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

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