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