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

[Jen Linkova <[e-mail]>]

On Thu, Sep 12, 2019 at 12:01 PM Gyan Mishra <[e-mail]> 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
> 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.

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.

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

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?

> On Thu, Sep 12, 2019 at 12:52 AM Gyan Mishra <[e-mail]> wrote:
>>
>> 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.  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
>>
>>
>
>
> --
> SY, Jen Linkova aka Furry



-- 
SY, Jen Linkova aka Furry