Subject: [v6ops] Fwd: New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

From: Chongfeng Xie <[email-masked]>
Date: Sun, 30 Jan 2022 10:36:59 +0800

Hi, all,
We have submitted a new draft as below. It mainly specifies requirements of multi-domain IPv6-only network from the perspective of operators.  Mutli-domain herein means a network is compose of multiple ASes and serves multiple scenarios, which is a common model for large-size operators.  This is only -00 draft and a start point, we are looking forward to receiving more comments and suggestions.   Thank you!

Best regards
Chongfeng

> 
> A new version of I-D, draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
> has been successfully submitted by Chongfeng Xie and posted to the
> IETF repository.
> 
> Name:		draft-xie-v6ops-reqirements-multi-domain-ipv6only
> Revision:	00
> Title:		Requirements to multi-domain IPv6-only network
> Document date:	2022-01-29
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only
> 
> 
> Abstract:
>   Dual-stack requires IPv4 and IPv6 are deployed in parallel, as it
>   costs more to run two technologies than one.  IPv6-only is considered
>   to be the next stage of IPv6 development from dual-stack.  This
>   document specifies requirements when deploying IPv6-only in multi-
>   domain networks.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 12:13:50 -0500

Hi Chongfeng

I have a draft that has been has been adopted by the BESS WG that is an
IPv6-Only PE design that uses RFC 5565 Softwire mesh framework which is
basically based on the concept of a single protocol core.  So a softwire is
basically a tunnel of IPv4 edge packets over an IPv6 only  core or IPv6
packets over an IPv4 only core.

The new innovative solution I am proposing is to help IXP peering points
resolve IPv4 address depletion issues around the world by making the PE
IPv6-Only eliminating all PE-CE IPv4 peering and carrying IPv4 prefixes
over IPv6 next hop peer using RFC 8950 next hop encoding and forwarding
IPV4 packets without PE-CE dual stack, basically processing the IPv4
packets and forwarding without having an IPv4 address configured on the
PE-CE interface.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00

I would be happy to collaborate as Co-author on your draft and provide
input from my IPv6-Only PE design.

Kind Regards

Gyan

On Sat, Jan 29, 2022 at 9:37 PM Chongfeng Xie <[email-masked]>
wrote:

>
> Hi, all,
> We have submitted a new draft as below. It mainly specifies requirements
> of multi-domain IPv6-only network from the perspective of operators.
> Mutli-domain herein means a network is compose of multiple ASes and serves
> multiple scenarios, which is a common model for large-size operators.  This
> is only -00 draft and a start point, we are looking forward to receiving
> more comments and suggestions.   Thank you!
>
> Best regards
> Chongfeng
>
>
>
>
>
>
> A new version of I-D,
> draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
> URL:
> https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only
>
>
> Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Chongfeng Xie <[email-masked]>
Date: Mon, 31 Jan 2022 07:44:13 +0800

Hi，Gyan，
Thank you for introducing your draft and willing to provide input from IPv6-only PE design. I will add you as co-author in the next version.

Best regsrds
Chongfeng

> 2022年1月31日 上午1:13，Gyan Mishra <[email-masked]> 写道：
> 
> 
> Hi Chongfeng
> 
> I have a draft that has been has been adopted by the BESS WG that is an IPv6-Only PE design that uses RFC 5565 Softwire mesh framework which is basically based on the concept of a single protocol core.  So a softwire is basically a tunnel of IPv4 edge packets over an IPv6 only  core or IPv6 packets over an IPv4 only core.  
> 
> The new innovative solution I am proposing is to help IXP peering points resolve IPv4 address depletion issues around the world by making the PE IPv6-Only eliminating all PE-CE IPv4 peering and carrying IPv4 prefixes over IPv6 next hop peer using RFC 8950 next hop encoding and forwarding IPV4 packets without PE-CE dual stack, basically processing the IPv4 packets and forwarding without having an IPv4 address configured on the PE-CE interface.
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00>
> I would be happy to collaborate as Co-author on your draft and provide input from my IPv6-Only PE design.
> 
> Kind Regards 
> 
> Gyan
> 
> On Sat, Jan 29, 2022 at 9:37 PM Chongfeng Xie <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi, all,
>> URL:            https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt <https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/ <https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only <https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only>
>> 
>> 
>> Abstract:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> -- 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 30 Jan 2022 16:05:50 -0800

I’m very interested in working group comments on this.

Sent from my iPad

> On Jan 29, 2022, at 6:37 PM, Chongfeng Xie <[email-masked]> wrote:
> 
> 
> 
> Hi, all,

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 22:29:08 -0500

Welcome,

Thank you

Gyan

On Sun, Jan 30, 2022 at 6:44 PM Chongfeng Xie <[email-masked]>
wrote:

> Hi，Gyan，
> Thank you for introducing your draft and willing to provide input from
> IPv6-only PE design. I will add you as co-author in the next version.
>
> Best regsrds
> Chongfeng
>
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 31 Jan 2022 10:27:12 +0000

Hi all,
Of course, it would be good to have “VPNv4aaS cross-carrier”, but …
IMHO: this draft rises the bar to “impossible” because it requests cooperation (and small expenses) from owners of the legacy IPv4 servers.
If such cooperation is possible then it is better to just activate IPv6 on all servers on the Internet (no need for VPNv4aaS at all).

More detailed explanation:

https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00 is discussing only control plane unification to IPv6-only. The Data plane still assumes Dual-Stack. It is perfectly possible.
draft-xie-v6ops-reqirements-multi-domain-ipv6only is asking for IPv6-only for the cross-carrier data plane too.

Consider any IPv4 session.
The IPv4 source could use any VPNv4aaS technology for all IPv4 traffic – it is not a problem (well, RFC 8585 compliancy is still a huge problem for FBB, but let's assume the best).
The IPv4 destination is a principal problem. It should send the traffic of some sessions to the special carrier gateway (for some sort of cross-carrier VPNv4aaS) but other sessions to IPv4 Internet.
Because would be some IPv4 sources that do not participate yet in “cross-carrier VPNv4aaS”.
Every owner of server resources should have some special policy forwarding (probably, on the gateway router) to split traffic properly between

-          A special carrier gateway (like PLAT) that would tunnel or translate (probably in IPv6) to cross-carrier VPNv4aaS

-          Normal IPv4 routing to the internet for Carriers that do not participate in cross-carrier VPNv4aaS
This policy forwarding should be managed from Carrier’s side! The carrier should update what is reachable by “cross-carrier VPNv4aaS” and what is not.
IMHO: such an additional policy forwarding requirement for legacy IPv4 servers defeats the purpose of the solution.
The server owner would probably prefer to enable IPv6 than to add special functionality to the router in front of the server farm, especially in the situation when it should be updated by Carrier.

The good news is that any server owner that would agree to activate policy routing managed by his carrier on the Internet gateway
Could start participation in “cross-carrier VPNv4aaS“ immediately, he does not need to wait for all other server owners – they could continue to send plain IPv4 to the global IPv4 Internet.
The particular Carrier would not become IPv6-only till the last one server owner would not enable Dual-Stack or install policy forwarding in front of it.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Monday, January 31, 2022 3:06 AM
To: [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

On Jan 29, 2022, at 6:37 PM, Chongfeng Xie <[email-masked]<mailto:[email-masked]>> wrote:

Hi, all,

Best regards
Chongfeng

Abstract:

The IETF Secretariat

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 31 Jan 2022 10:50:51 +0000

Theoretically, this policy filtering could be moved to carriers PEs.
It looks like yet another Lawful Intercept:
if the destination address is in the long filter of Carrier’s prefixes supporting “VPNv4aaS cross-carrier” then forward it to “VPNv4aaS cross-carrier PLAT” (for translation or encapsulation to IPv6).
I doubt that many carriers would agree to such a solution.
Ed/
From: Vasilenko Eduard
Sent: Monday, January 31, 2022 1:29 PM
To: 'Fred Baker' <[email-masked]>; [email-masked]
Subject: RE: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

Hi all,

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Monday, January 31, 2022 3:06 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

Hi, all,

Best regards
Chongfeng

Abstract:

The IETF Secretariat

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 31 Jan 2022 11:26:14 +0000

The 3rd option comes to my mind (everyone next is worse than the previous) for
How to push traffic to “VPNv4aaS cross-carrier PLAT” on the Server side: Let’s push all IPv4 traffic to the PLAT bottleneck!
If the destination is not on the filter as “VPNv4aaS cross-carrier PLAT” accessible then just forward it to the IPv4 Internet without any change of headers. Traffic that is possible to access inside “VPNv4aaS cross-carrier” should be translated or encapsulated.
And again, I am very doubtful of acceptance.
Eduard
From: Vasilenko Eduard
Sent: Monday, January 31, 2022 1:52 PM
To: 'Fred Baker' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

To: 'Fred Baker' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi all,

Eduard

Hi, all,

Best regards
Chongfeng

Abstract:

The IETF Secretariat

---

From: Chongfeng Xie <[email-masked]>
Date: Tue, 1 Feb 2022 10:07:18 +0800

Hi，Eduard,
Thank you for your comments.  Although the draft I submitted is about requirement, I’d like to share some of my personal understanding of IPv4 As A service. Firstly, I don’t think it is a VPN-like stuff,  although the legacy IPv4 service data is encapsulated or translated into IPv6 when it traverse IPv6-only network , it is open to the public Internet, and not private, the only difference lies in the routing and data format.  Secondly, the requirements listed in this draft do not include the request of the cooperation of legacy servers. In order to support the access of the residual service of the IPv4 Internet,  a special carrier gateway may be needed, as you mentioned. From the standpoint from one large-scale operator,  a scalable, lightweight ,open, and secure solution should be available to meet the requirements, it may integrate some  the existing IPv6-only techniques, new components may also be needed. I hope more and more constructive suggestions can be raised and become  input to the requirement draft.

Best regards
Chongfeng

> 2022年1月31日 下午6:27，Vasilenko Eduard <vasilenko.eduard=[email-masked]> 写道：
> 
> Hi all,
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00> is discussing only control plane unification to IPv6-only. The Data plane still assumes Dual-Stack. It is perfectly possible.
> From: v6ops [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Fred Baker
> To: [email-masked] <mailto:[email-masked]>
> On Jan 29, 2022, at 6:37 PM, Chongfeng Xie <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>  
> Hi, all,