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

From: Nick Matthews <matthn_at_gmail.com>
Date: Mon, 18 Jul 2011 09:01:30 -0700

You will likely be more interested in NAT64 or for servers a SLB with
64 support.

-nick

On Thu, Jul 14, 2011 at 9:13 PM, Prakash Kalsaria
<kalsaria.prakash_at_gmail.com> wrote:
> Thanks all .....
>
> Great info's
>
>
> On Thu, Jul 14, 2011 at 10:21 PM, Narbik Kocharians <narbikk_at_gmail.com>wrote:
>
>> 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
> <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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Jul 18 2011 - 09:01:30 ART

This archive was generated by hypermail 2.2.0 : Mon Aug 01 2011 - 06:30:06 ART