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

[Erik Kline <[e-mail]>]

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]> 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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>