Re: [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6

[Chongfeng Xie <[e-mail]>]

Hi Jeff,

Thank you for your feedback.

Based on your comment and suggestions, we have made the following revisions and submitted a new version, 

1. In section 1, the following sentence is added to show that  the approach in the draft mainly focuses on controlled environment, 
     "It should be noted that the approach in this document focuses on is controlled environment, for instance, one network of  single network operator or small network of cooperating network operators. One effect of using this approach is that the IPv4 address prefix in it will be given one IPv6 mapping  prefix and advertised in a IPv6 mapping route."

2. In section 2, the term of Distance metric has been removed, the structure of the mapping database in PE is changed accordingly.

3. In section 3.2, the value of  Address Origin Type's field is illustrated.

4. In section 3.2,  'IPv4 Original ASN' field is removed from the 4map6 attribute.

5.  Section 3.3 has been deleted.

6. Since the term of 'Distance metric' is removed, P router does not need to do route selection, procedures in section 4.2 and 4.3 is revised accordingly.

7. Section 7 of “Deployment and operation considerations”is added, it mainly analyses the issues of scalability and route distribution control.  In particular, it discusses IPv6 mappring prefix allocation in multi-operator envirionment. Moreover, some proposal is provided to prevent IPv6 mapping routes from leaving the IPv6-only network and entering the IPv6 Internet, the possible effect of this to IPv6 Internet is also mentioned when this does happens.

8. In section 7.1, the use of WKP and NSP is illustrated in combination with the mapping prefix configuration for different types of PE. 

9. Section 8 of "Security considerations" is revised by adding the authenticity of 4map6 information, some are cited from draft-ietf-v6ops-framework-md-ipv6only-underlay.

10. Some editorial changes have been made.

If you have any further comments, please feel free to let me know. 


Best regards
Chongfeng



Name:     draft-xie-idr-mpbgp-extension-4map6
Revision: 08
Title:    MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
Date:     2024-01-29
Group:    idr
Pages:    15
URL: https://www.ietf.org/archive/id/draft-xie-idr-mpbgp-extension-4map6-08.txt
Status: https://datatracker.ietf.org/doc/draft-xie-idr-mpbgp-extension-4map6/
HTMLized: https://datatracker.ietf.org/doc/html/draft-xie-idr-mpbgp-extension-4map6
Diff: https://author-tools.ietf.org/iddiff?url2=draft-xie-idr-mpbgp-extension-4map6-08


 
From: Jeffrey Haas
Date: 2024-01-27 00:27
To: Chongfeng Xie
CC: Sue Hares; idr; draft-xie-idr-mpbgp-extension-4map6
Subject: Re: [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6
Chongfeng,


On Jan 26, 2024, at 12:52 AM, Chongfeng Xie <[e-mail]> wrote:
Thank you for your comments, suggestions and questions. Based on your suggestions, I’d like to make some revisions to the draft as below,

1) P router does not need to do route selection and the term of Distance metric is removed.

This will be quite helpful in making incremental deployment of the feature safer.

2) The IPv4 prefix will be given only one IPv6 mapping prefix (Network Specific Prefix) in IPv6 network and advertised in a mapping route.
3) The approach in the draft mainly focuses on controlled environment, for instance, the network of one carrier.

These clarifications will significantly address the scalability concerns and help readers of the document better understand the scope of the proposal.

 
Scaling Considerations:
 

[Chongfeng]:  This draft proposes to map the IPv4 BGP route to the BGP route of IPv6 networks for transmission, that is called IPv6 mapping route, as you mentioned earlier, the prefix of NLRI is composed of IPv6 mapping prefix, denoted by M6, and IPv4 Network, denoted by N4. With this structure, M6 can identify the position of IPv4 network N4 at the edge of IPv6 network. 

Based on your suggestion, the proposal will be changed that the IPv4 prefix will be given ONLY one IPv6 mapping prefix for its advertisement in IPv6 network, even if it may be advertised by multiple PEs from difference places. We can discuss its implementation and feasibility based on the types of PE in actual networks, the devices at the edge of the operator's network can be divided into two types. 

It's less critical that the proposal change to support exactly one mapping prefix and more that the considerations when more than one such prefix is in use is understood.

draft-ietf-v6ops-framework-md-ipv6only-underlay helps us understand that two possible scenarios are the well-known-prefix and the network-specific-prefix.  If the common use case is the WKP scenario, that can help address scaling considerations.  Discussing WKP in multi-provider scenarios might be good text to add in the document if this is the direction the proposal goes.


One is the edge devices that are not interconnected with the external IPv4 network. They are configured with the operator's own IPv4 address block, such as BNG, and assigning an IPv6 address mapping prefix identify the location of the IPv4 network at the edge of the IPv6 network, generally, one mapping prefix for each IPv4 network is ok.  

For such situations, it seemed that NSP mode would be fine.  However, this highlights the cases where more than one service provider provides a mapping for that IPv4 address block under a different NSP.  This could be a misconfiguration.  This could be a hijack.

For situations that resemble hijacks, technologies such as RPKI origin validation or IRR filtering are able to help prevent this.  Applying such technologies to the proposed mapping mechanism would mean that BGP prefix policy would need to be able to be applied to the embedded IPv4 networks.  Currently such technologies don't exist as they would require all routers that desire to do such filtering to be able to parse the proposed mapped NLRI format.

I realize your intended deployment scenario is a small closed network of cooperating providers.  However, it is necessary to also analyze how the general IPv6 Internet would react to such routes if they either accidentally leave the closed network, or were intentionally injected as a hijacking mechanism.

Another type is router devices that are interconnected with the external IPv4 Internet, such as CRs, and there are usually multiple CRs in the network, distributed in different geographical locations. As CR devices receive IPv4 routing of N4 and announce it to the IPv6 network after mapping, they need to be assigned an IPv6 mapping prefix. It is recommended that all CRs share the same IPv6 mapping prefix, so that regardless of which CRs announce N4 to the IPv6 network, the prefixes of the NLRI they generate are the same, and the advantage of this is that IPv6 routers can select and transmit according to conventional IPv6 routing methods, such as combining next-hop information. 

When each IPv4 network uses only one IPv6 mapping prefix in the network, the RIB table of IPv6 will not expand, and the scalability issue will be solved.

I agree!

FIB Implications:
 
One interpretation of this sentence is it is your intent that when a IPv6
BGP Speaker receives a mapping prefix, perhaps identified by having the
4map6 Path Attribute, that it should not install that IPv6/unicast NLRI in
the FIB.  Is that your intent?

[Chongfeng]: Yes, the R router should not install that IPv6/unicast NLRI in the FIB.
 
If so, there are two issues with this desired procedure:
1. Only routers that understand this feature would be able to perform the
   optimization to avoid installing the mapping prefix into its IPv6 FIB.
2. As we had discussed in our previous emails, if the 4map6 Path Attribute
   were accidentally (or intentionally) removed, IPv6 FIB resources would be used.
 
It should be noted that many routers currently size the space of their IPv4
and IPv6 FIBs differently.  Significant redistribution of IPv4 Internet into
this mechanism can result in IPv6 FIB exhaustion.  If more than one service
provider distributes mapping prefixes for the same IPv4 networks, this issue
is compounded.
 
This is perhaps not the expected operational model or impact.  If that's the
case, some text emphasizing the scaling considerations may be helpful.
(If it hurts, don't do that!)

[Chongfeng]: This problem can be solved in two ways, one is through operational means. As the IPv6 prefix of NLRI generated through mapping is longer than that of regular IPv6 routes, the sum of the lengths of M6len and N4len is generally greater than 64. But in IPv6 BGP routing of carrier network, the prefix of NLRI is required to be less than a certain length, such as 48 bits. If a device that does not recognize this attribute or the attribute is accidentally lost, the router can filter it out or reject it. Another approach is to apply for a specific SAFI value for the approach in this draft, which is more conducive to the correct identification and judgment of routers. This proposal has been discussed before.

I understand your desired operational model.

For a closed network of cooperating providers, the IPv6 mapping prefix/prefixes can be provisioned to not be installed in the FIB of participating routers.  

For routers that aren't intentionally participating in this mechanism, perhaps via routing leak, or routers that do not have this FIB install rule, scaling may be impacted.  It would be good to call out this case operationally if the mechanism remains in its current form.

If we are willing to consider a new SAFI, this does create opportunities for safer procedures.  As we discussed in-person at IETF 118, if the deployment model is able to change from not having the mapping routes distributed in the existing IPv6/unicast Internet routes, we can consider other options.  In particular, instead of overloading the IPv6 format of the NLRI, the new SAFI could use IPv4 NLRI and carry the IPv6 mapping prefix as an attribute wholly.  Perhaps instead of needing a new path attribute, the mapping prefix can be included in the existing Tunnel Encapsulation Attribute.

The primary impact of moving to a new SAFI is that distribution of mapping prefixes ceases to be done on a hop-by-hop basis.  However, since the use case is "tunnel across the IPv6 forwarding infrastructure", very little changes in the forwarding portion of the proposal.

 
Route Selection and Route Propagation Considerations:
 
I suspect Section 3.3 needs to be deleted, but that depends if my
understanding of your intent in the next sections is correct.

[Chongfeng]: I agree, Section 3.3 will be deleted in the next version.
This removes a significant concern of the proposal.  Thanks.

The draft then says:
 
"Advertise the updated content of the entry found in the form of
MP_REACH_NLRI update information to IPv6 peer routers."
 
If I am understanding this correctly, your intention is that the receiving
BGP Speaker only will propagate BGP Routes that are the best entry in the
mapping database.  Is this correct?

[Chongfeng]: I will change this part. In IPv6 network BGP routes for a given IPv6 mapping prefix have not major difference to that of native IPv6 route, I think this can follow the typical BGP process of native IPv6 routes, in addition, "route selection" in P router will be removed.  
Again, this removes a significant concern of the proposal. Thanks.

[Chongfeng]: I will change this procedure, we will not use the mapping database entry selection. When P router receives a mapping route, it processes it in the way same to that of native IPv6 routing, The metric distance is not used for route selection any longer, this term will be deleted from the draft as well.

[Chongfeng]: Although this is a management and operational issue, for operators, it is important to promptly identify and resolve this issue to avoid any impact on the external IPv6 Internet. But if it does happen, due to its use of longer NLRI Prefix, the general purpose BGP router will filter out these routing advertisements.

In the well-known-prefix form of the proposal, it becomes very easy for operators to understand common practice for filtering such routes.

For the other cases, while very long prefix lengths are often good reasons to filter routes, there is no guarantee that such practices are consistently implemented right now.  Additionally, other clever protocol developers may wish to have other reasons for longer routes.  For example, SRv6 use cases.
Again thank you so much for raising so many questions and comments. Even though I have tried to answer them, I am not sure whether I have completely understood all of them and given adequate and reasonable feedback, if not, please raise them and we can continue our discussion.
I understand your answers and look forward to reviewing the next iteration of the proposal.

-- Jeff