[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Question for w.g. on <<draft-ietf-6man-ra-pref64-04>
From: Gyan Mishra <hayabusagsm () gmail ! com>
Date: 2019-09-18 3:32:50
Message-ID: CABNhwV2W=kdsZiDxVnv9JDtO1p5FFvpaU6=KQt+CeB_LTKw5pw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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: 301 502-1347
Email: gyan.s.mishra@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
On Thu, Sep 12, 2019 at 12:29 PM Bob Hinden <bob.hinden@gmail.com> wrote:
> Jen,
>
> > On Sep 11, 2019, at 10:28 PM, Jen Linkova <furry13@gmail.com> wrote:
> >
> > On Thu, Sep 12, 2019 at 12:01 PM Gyan Mishra <hayabusagsm@gmail.com>
> 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: 301 502-1347
Email: gyan.s.mishra@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
[Attachment #5 (text/html)]
<div dir="ltr">Jen<div><br></div><div>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. \
</div><div><br></div><div>Thank you</div><div><br></div><div><div><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Gyan S. Mishra</span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)"><span \
style="background-color:rgba(255,255,255,0)">IT Network Engineering & Technology \
</span></span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Verizon Communications \
Inc. (VZ)</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">13101 Columbia Pike FDC1 \
3rd Floor</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Silver Spring, MD \
20904</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">United States</span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Phone: 301 \
502-1347</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Email: <a \
href="mailto:gyan.s.mishra@verizon.com" style="color:blue" target="_blank"><span \
style="color:rgb(17,85,204)">gyan.s.mishra@verizon.com</span></a></span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)"><span \
style="color:black"><a \
href="http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT" \
style="color:blue" target="_blank">www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT</a></span></span></p></div><div></div></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 12, 2019 at 12:29 \
PM Bob Hinden <<a href="mailto:bob.hinden@gmail.com">bob.hinden@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jen,<br> <br>
> On Sep 11, 2019, at 10:28 PM, Jen Linkova <<a href="mailto:furry13@gmail.com" \
target="_blank">furry13@gmail.com</a>> wrote:<br> > <br>
> On Thu, Sep 12, 2019 at 12:01 PM Gyan Mishra <<a \
href="mailto:hayabusagsm@gmail.com" target="_blank">hayabusagsm@gmail.com</a>> \
wrote:<br> >> 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<br> >> as 13 \
bits would give 8192 seconds (2.5 hours) versus 16 bits 65535 seconds (18 hours)<br> \
>> The slaac prefix valid lifetime default is 30 days<br> >> 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.<br> > <br>
> I believe the proposal was to calculate the actual lifetime by<br>
> multiplying the Lifetime field value by 8, not having the shorter<br>
> lifetime.The reason is:<br>
> the prefix lifetime should not be shorter than the router lifetime,<br>
> otherwise it's possible for the prefix to expire before the next RA<br>
> arrives.<br>
> <br>
>> One last question I had is on the 4 byte prefix option which contains \
the<br> >> IPv4 address that would be embedded per RFC6052 that is being \
removed - does that not<br> >> have to be present for DNS64 IPv6 RR synthesis \
to occur for "non /96" prefix<br> >> lengths.<br>
> <br>
> If I understand you correctly you are saying that with the new<br>
> proposed format we can not specify the suffix? Actually it's a very<br>
> good question and that's exactly why the format we have in the draft<br>
> still has all 128 bits - in case we need the suffix.<br>
> <br>
> Currently the suffix is expected to be 0 but RFC6052 says<br>
> 'These bits are reserved for future extensions<br>
> and SHOULD be set to zero. Address translators who receive IPv4-<br>
> embedded IPv6 addresses where these bits are not zero SHOULD ignore<br>
> the bits' value and proceed as if the bits' value were zero. \
(Future<br> > extensions may specify a different behavior.)'.<br>
> <br>
> Good question - so the benefit of the format in the draft is that we<br>
> can encode the suffix if needed (in addition to better representation<br>
> of the lifetime).<br>
> Ole, Bob, what do you think?<br>
> There is no case for non-zero suffix now but shall we assume that it's<br>
> not going to change, esp. providing RFC6052 allows that?<br>
<br>
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.<br> <br>
I lean to not doing anything now, seems unlikely to happen to me.<br>
<br>
Bob<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><p class="MsoNormal" \
style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Gyan S. Mishra</span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)"><span \
style="background-color:rgba(255,255,255,0)">IT Network Engineering & Technology \
</span></span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Verizon Communications \
Inc. (VZ)</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">13101 Columbia Pike FDC1 \
3rd Floor</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Silver Spring, MD \
20904</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">United States</span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Phone: 301 \
502-1347</span></p><p class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)">Email: <a \
href="mailto:gyan.s.mishra@verizon.com" style="color:blue" target="_blank"><span \
style="color:rgb(17,85,204)">gyan.s.mishra@verizon.com</span></a></span></p><p \
class="MsoNormal" style="margin:0in 0in \
0.0001pt;background-image:initial;background-position:initial;background-repeat:initial;font-size:12pt;font-family:"Times \
New Roman",serif"><span \
style="font-family:Calibri,sans-serif;color:rgb(80,0,80)"><span \
style="color:black"><a \
href="http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT" \
style="color:blue" target="_blank">www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT</a></span></span></p></div><div><br></div></div></div></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic