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

[Bob Hinden <[e-mail]>]

Jen,

> On Sep 11, 2019, at 10:28 PM, Jen Linkova <[e-mail]> wrote:
> 
> 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?

Seems to me that to start using non-zero suffixs several IETF specifications and, of course, many implementations would have to change.   There would need to be a strategy for how to deploy it given the resulting mixed implementations.   Doing a “bis” of this specification would be the easy part.

I lean to not doing anything now, seems unlikely to happen to me.

Bob