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

[Gyan Mishra <[e-mail]>]

Jen

I am good with the proposed format which gives flexibility for current and
future implementations then implementing the suffix now and better
representation of lifetime.  So I agree to not doing anything now since
"non /96" use cases are unlikely.  Since many implementations exist with
nat64 w/ /96 all 0s suffix that adding the non zero suffix now would be
complicated as existing implementations and resulting interoperability
issues with a variety of mixed options formats  and as Bob mentioned
changing the specification would be the easier then all the options
permutations of resulting implementations.

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 Thu, Sep 12, 2019 at 12:29 PM Bob Hinden <[e-mail]> wrote:

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

-- 

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