Source IPv6 and Destination IPv4 can we perform routing in this scenario
Prakash Kalsaria
Prakash Kalsaria
Well, and Ipv6 packet will never have an IPv4 address as the destination natively, so that may answer the first part of your question.
Because someplace along the way, you'll need to tell the source about SOME address to use as the IPv6 destination.
If your destination really is an IPv4 host, then again, someplace along the way, there will need to be a change (NAT) between the v6 information and the v4 information.
HTH,
Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CCDE #2009::D, JNCIE-M #153, JNCIE-ER #102, CISSP, et al.
CCSI #21903, JNCI-M, JNCI-ER
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
Prakash Kalsaria
Here is an interesting NAT-PT configuration with a little twist, if you are interested. Sorry for typos.
Topology:
R1 and R3 are connected via their S0/1 interface using HDLC encapsulation. R1’s S0/1 is configured with 13::1/64, and R3’s S0/1 interface is configured with 13::3/64 IPv6 addressing.
R3 and R4 are connected via their S0/0 using Frame-relay encapsulation. R3’s S0/0 is configured with 10.1.34.3/24 and R4’s S0/0 is configured with 10.1.34.4/24.
R1 –(S0/1= 13::1/64)----------(S0/1=13::3/64)--- R3 (S0/0=10.1.34.3/24)----------(S0/0=10.1.34.4/24) R4
----------------------------- IPv4 -------------------------IPv6---------------------------
Configure the following link-local addressing:
Router
Interface
Link-Local address
R1
S0/1
FE80::1
R3
S0/1
FE80::3
Task 1
Configure R3 such that the IPv4-ONLY host (R4) can Ping and communicate with IPv6-ONLY host R1. DO NOT configure R1 or R4 as dual stack to accomplish this task.
NAT-PT is designed to allow direct communication between IPv6-ONLY and IPv4-ONLY networks.
This is one of many solutions that can accommodate IPv4 to IPv6 migration. One of the attractive points with NAT-PT is the fact that it does NOT require any modifications to the existing devices, because the entire configuration is performed on the NAT-PT device. In this case R3.
In this solution, a static map is configured to statically map an IPv6 to an IPv4 address; since this has to be done for every host on that network, this solution is NOT scalable.
To configure this task:
On R3
In the first step of this configuration, IPv6 NAT-PT must be enabled on the interfaces that translation must occur; this MUST be configured on the NAT-PT device. The following command enables NAT-PT on the S0/1 and S0/0 interfaces:
R3(config)#Int S0/1
R3(config-if)#IPv6 nat
R3(config)#Int S0/0
R3(config-if)#IPv6 nat
In the next step of this configuration, the static mappings are configured:
R3(config)#IPv6 nat V6V4 source 13::1 10.1.34.1
In the above configuration, R1’s IPv6 address of 13::1 is mapped to an IPv4 address of 10.1.34.1. Remember that this IP address does NOT exist on the link between R3 and R4; this is just an IP address that is used for the mapping.
In the following step the source IP address of R4 (10.1.34.4) is mapped to an imaginary IPv6 address. This IPv6 address may or may NOT exist on the IPv6 side of the network; this IPv6 address will be used as the IPv6 prefix address and it MUST be a /96 address:
R3(config)#IPv6 nat V4V6 source 10.1.34.4 14::1
In the final step, the IPv6 prefix is configured:
R3(config)#IPv6 nat prefix 14::1/96
Some important points to remember:
- The prefix is a 96 bit field that allows routing back to the NAT-PT device.
- The IPv6 host pings with its IPv6 address as the source and the 14::1 as the destination.
- NAT-PT device services the flow and sets the source as 10.1.34.1 and the destination as 10.1.34.4.
- The IP device responds with 10.1.34.4 as the source and the 10.1.34.1 as the destination.
- The NAT-PT device receives the flow and sets the source IPv6 address as the 14::1 and the destination to 13::1.
NOTE: Once the above configuration is complete, the 14::/96 shows up in the routing table of the NAT-PT device as a directly connected interface:
On R3
R3#Show ipv6 route connected | Inc 14::/96|NV
C 14::/96 [0/0]
via ::, NVI0
The NAT Virtual Interface (NVI) feature allows all NAT traffic flows on the virtual interface, eliminating the need to specify inside and outside domains.
In the final step RIPng is configured between R1 and R3 and the 14::/96 is redistributed into the RIPng routing domain so R1 can see and have reachability to this prefix.
On R1 and R3
Rx(config)#IPv6 unicast-routing
Rx(config)#Int S0/1
Rx(config-if)#IPv6 rip TST enable
On R3
R3(config)#IPv6 router rip TST
R3(config-rtr)#Redistribute connected metric 1
To verify the configuration:
On R1
R1#Sh ipv6 route rip | Inc 14::/96
R 14::/96 [120/2]
In order to test this configuration, “Debug ip icmp” is configured on R4 while a ping is generated from R1:
To test the configuration:
On R4
R4#Debug ip icmp
On R1
R1#Ping 14::1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 14::1, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
Let’s check the output of the debug command on R4:
On R4
ICMP: echo reply sent, src 10.1.34.4, dst 10.1.34.1
This looks pretty good, but it’s still NOT working. Let’s enable “Debug IP packet” on R4 and analyze the output:
On R4
R4#Debug ip packet
On R1
R1#Ping 14::1 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 14::1, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
On R4
IP: tableid=0, s=10.1.34.1 (Serial0/0), d=10.1.34.4 (Serial0/0), routed via RIB
IP: s=10.1.34.1 (Serial0/0), d=10.1.34.4 (Serial0/0), len 80, rcvd 3
IP: tableid=0, s=10.1.34.4 (local), d=10.1.34.1 (Serial0/0), routed via RIB
IP: s=10.1.34.4 (local), d=10.1.34.1 (Serial0/0), len 80, sending
IP: s=10.1.34.4 (local), d=10.1.34.1 (Serial0/0), len 80, encapsulation failed
We can see the problem, R4 does NOT have a Frame-relay map for 10.1.34.1 prefix, therefore, R4 gets encapsulation failure. Let’s add a frame-relay map to R4 mapping 10.1.34.1 to R4’s DLCI 403 and test again:
On R4
R4(config)#Int S0/0
R4(config-if)#Frame-relay map ip 10.1.34.1 403
On R1
R1#Ping 14::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 14::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/72 ms
To test the traffic in the opposite direction (From R4 to R1):
Let’s enable “Debug IPv6 packet” on R1 and Ping 10.1.34.1 from R4:
On R1
R1#Debug IPv6 Packet
On R4
R4#Ping 10.1.34.1 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.1.34.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 88/88/88 ms
On R1
IPV6: source 14::1 (Serial0/1)
dest 13::1
traffic class 0, flow 0x0, len 128+4, prot 44, hops 253, forward to ulp
IPv6: nexthop FE80::3,
source 13::1 (local)
dest 14::1 (Serial0/1)
traffic class 0, flow 0x0, len 120+4, prot 58, hops 64, originating
IPv6: Sending on Serial0/1
To see the translation table:
On R3
R3#Show ipv6 nat translations verbose
Prot IPv4 source IPv6 source
IPv4 destination IPv6 destination
--- --- ---
10.1.34.4 14::1
create 01:40:35, use 00:00:07,
icmp 10.1.34.1,7199 13::1,7199
10.1.34.4,7199 14::1,7199
create 00:00:07, use 00:00:06, left 00:00:53,
--- 10.1.34.1 13::1
--- ---
create 01:46:59, use 00:00:07,
The IPv6 address of 13::1 is translated to 10.1.34.1 IP address, meaning that R4 can communicate with R1 by using 10.1.34.1 IP address; whereas, R1 will use an IPv6 address of 14::1 to communicate with R4.
On Wed, Jul 13, 2011 at 11:17 AM, Eoghan Cullen <eoghan...@gmail.com> wrote:
http://tools.ietf.org/html/rfc4966
On 12 July 2011 23:02, Joe Astorino <joeasto...@gmail.com> wrote:
> In addition to what others have said, you might want to specifically read
> up
> on NAT-PT
>
> On Tue, Jul 12, 2011 at 8:34 AM, Scott Morris <s...@emanon.com> wrote:
>
> > Well, and Ipv6 packet will never have an IPv4 address as the destination
> > natively, so that may answer the first part of your question.
> >
> > Because someplace along the way, you'll need to tell the source about
> > SOME address to use as the IPv6 destination.
> >
> > If your destination really is an IPv4 host, then again, someplace along
> > the way, there will need to be a change (NAT) between the v6 information
> > and the v4 information.
> >
> > HTH,
> >
> > Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> >
> > CCDE #2009::D, JNCIE-M #153, JNCIE-ER #102, CISSP, et al.
> >
> > CCSI #21903, JNCI-M, JNCI-ER
> >
> > s...@emanon.com
> >
> > Knowledge is power.
> >
> > Power corrupts.
> >
> > Study hard and be Eeeeviiiil......
> >
> > On 7/12/11 1:55 AM, Prakash Kalsaria wrote:
> >
Narbik Kocharians> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> Blog: http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
--
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
Sr. Technical InstructorAsk about our FREE Lab Voucher with our Boot CampsYES! We take Cisco Learning Credits!
Training & Remote Racks available