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

[Jen Linkova <[e-mail]>]

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

-- 
SY, Jen Linkova aka Furry