Re: Source IPv6 and Destination IPv4 can we perform routing in

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.
R1s S0/1 is configured with 13::1/64, and R3s S0/1 interface is configured
with 13::3/64 IPv6 addressing.*

*R3 and R4 are connected via their S0/0 using Frame-relay encapsulation.
R3s S0/0 is configured with 10.1.34.3/24 and R4s 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, R1s 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)*

* *

*Lets 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 its still NOT working. Lets 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. Lets add a frame-relay
map to R4 mapping 10.1.34.1 to R4s 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):*

* *

*Lets 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
<eoghancullen_at_gmail.com>wrote:

> http://tools.ietf.org/html/rfc4966
>
>
> On 12 July 2011 23:02, Joe Astorino <joeastorino1982_at_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 <swm_at_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
> > >
> > > swm_at_emanon.com
> > >
> > > Knowledge is power.
> > >
> > > Power corrupts.
> > >
> > > Study hard and be Eeeeviiiil......
> > >
> > > On 7/12/11 1:55 AM, Prakash Kalsaria wrote:
> > >
> > > Hi all
> > >
> > > I like to have some idea
> > > if Source is IPv6 and I other end i have to IPv4 (destination) for
> > > routing
> > > can i acheive this With any means
> > >
> > > Regards Prakash Kalsaria
> > >
> > >
> > > 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
>
>
>
>
>
>
>
>

--
*Narbik Kocharians
*CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com <http://www.micronicstraining.com/>
Sr. Technical Instructor
*Ask about our FREE Lab Voucher with our Boot Camps*
YES! We take Cisco Learning Credits!
Training & Remote Racks available
Blogs and organic groups at http://www.ccie.net