Hi Tom,

Thank you for your question.


I-D./draft-ietf-v6ops-framework-md-ipv6only-underlay proposes a framework for 
deploying IPv6-only as underlay in multi-domain networks. In this draft, 
IPv6-only network support the following scenarios,
Scenario 1: IPv6 user to IPv4 server, i.e., IPv6-only user accesses IPv4 
services hosted in data centers.
Scenario 2: IPv4 user to IPv4 server, i.e., IPv4-only user accesses IPv4 
services hosted in data centers.
Scenario 3: IPv6 user to IPv6 server, i.e., IPv6-only user accesses IPv6 
services hosted in data centers.
Scenario 4: DC-to-DC, i.e., IPv6-only network provides communications between 
servers hosted in data centers, despite they are IPv4, IPv6 or IPv4/IPv6 
dual-stack.
Scenario 5: Transit for neighbor networks, i.e., IPv6-only network serves as an 
interconnection between several segregated IPv4-only networks, IPv4 packets are 
transported over the IPv6-only network between IPv4 networks.


- To support the forwarding of IPv4 service data, multi-domain IPv6-only 
network needs to transform IPv4 packets into IPv6 ones in the UE/CPE or at the 
edge of the network. 


- In addition, RFC5549/8950 deals with how to advertise IPv4 Network Layer 
Reachability Information with an IPv6 Next Hop, it does not consider how to 
create the IPv6 address of the new packet for transmission in IPv6-only network.


- So, 4map6 segments is defined. They run in PE nodes and provide support for 
implementing IPv4/IPv6 conversion function based on mapping rules.




Best regards,
Guozhen
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to