Subject: Fwd: 6man w.g. last call for <draft-ietf-6man-ra-pref64-03>

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Aug 2019 08:48:19 -0700

This w.g. last call ends on 8 August 2019.

Bob & Ole

> Begin forwarded message:
> 
> From: Ole Troan <[email-masked]>
> Subject: 6man w.g. last call for <draft-ietf-6man-ra-pref64-03>
> Date: July 25, 2019 at 1:37:14 PM PDT
> To: 6man WG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: [email-masked], [email-masked]
> 
> Hello,
> 
> This message starts a new two week 6MAN Working Group Last Call on advancing:
> 
>  Title    : Discovering PREF64 in Router Advertisements
>  Author   : J. Linkova, L. Colitti
>  Filename : draft-ietf-6man-ra-pref64-03
>  Pages    : 11
>  Date     : 2019-07-24
> 
>    https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/
> 
> as a Proposed Standard.
> 
> Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on the 8th of August 2019.
> 
> To improve document quality and ensure that bugs are caught as early as possible, we would require at least two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.
> 
> Thanks,
> Bob & Ole, 6man co-chairs

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 5 Aug 2019 19:43:04 -0400

I have reviewed and support moving forward this document for advancing.
The document is well written and touches on all pertinent discussion
points.

I agree that this draft will help with proliferation of IPv6 only
environments ad make Enterprise & Service Provider environments more viable
using NAT64 RFC 6146 and DNS64 RFC 6147 with this 3rd alternative means of
pref64 discovery.

One question I did have is that today we do have the other discovery
mechanisms for pref64 with RFC 7050(PCP discovery) & RFC 7225(IPv6 address
synthesis).  For my own edification and maybe others what are the issues
with host OS's not being able to support the other two discovery mechanisms
which would lead us to part of what should be included in a problem
statement and that is why we have come up with the RA method to advertise
the prefix as the 3rd discovery method.

I don't think I saw that mentioned in the draft which is why I am asking.

Section 6 - Middle of page 7

  When different Pref64 are discovered by using multiple mechanisms, hosts
SHOULD select one source of infromation only.
   The RECOMMENDED order is:
 o PCP-discovered prefixes ([RFC7225]), if supported;
 o Pref64 discovered via RA Option;
 o Pref64 resolving IPv4-only fully qualified domain name ([RFC7050])

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: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

On Thu, Jul 25, 2019 at 4:37 PM Ole Troan <[email-masked]> wrote:

> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list. Editorial suggestions can
> be sent to the author. This last call will end on the 8th of August 2019.
>
> To improve document quality and ensure that bugs are caught as early as
> possible, we would require at least two reviewers to do a complete review
> of the document.  Please let the chairs know if you are willing to be a
> reviewer.
>
> Thanks,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 

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: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

---

From: Jen Linkova <[email-masked]>
Date: Tue, 6 Aug 2019 13:54:09 +1000

Hi Gyan,

On Tue, Aug 6, 2019 at 9:44 AM Gyan Mishra <[email-masked]> wrote:
> One question I did have is that today we do have the other discovery mechanisms for pref64 with RFC 7050(PCP discovery) & RFC 7225(IPv6 address synthesis).  For my own edification and maybe others what are the issues with host OS's not being able to support the other two discovery mechanisms which would lead us to part of what should be included in a problem statement and that is why we have come up with the RA method to advertise the prefix as the 3rd discovery method.

Section 3 does discuss the reasons for introducing an RA option and
benefits of the proposed approach comparing to existing mechanisms:
https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-03#section-3

Please let me know if it does not address your concern.
Thanks!

-- 
SY, Jen Linkova aka Furry

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 7 Aug 2019 03:57:17 -0400

Hi Jen

That section does clearly explain the reasons why the other discovery methods for IPv6 address synthesis take longer and are best effort discovery methods that may be slower then a Pre64 RA advertisement method in this draft similar to slaac so the dns64 nat alg response can  succeed for the nat64 stateful dynamic IPv4 overload port translation to occur so the 6to4 session can be established.

I think this will really help Enterprises and service providers to deploy IPv6 only customer networks.

I fully support advancement of this document.

Thanks 

Gyan
Sent from my iPhone

> On Aug 5, 2019, at 11:54 PM, Jen Linkova <[email-masked]> wrote:
> 
> Hi Gyan,
>