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

[Alexandre Petrescu <[e-mail]>]

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?
> 
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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
>           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
> 
> 
> 
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[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
> --------------------------------------------------------------------
>