White	
  Paper	
  
Service	
  Provider	
  Transition	
  to	
  IPv6:	
  NAT,	
  NAT64,	
  
6RD,	
  DS-­‐LITE	
  and	...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   2	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   3	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   4	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   5	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   6	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   7	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   8	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   9	
  
	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  
...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   1
0	
  	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  ...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   1
1	
  	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  ...
  Service	
  Provider	
  Transition	
  to	
  IPv6	
   1
2	
  	
  
Fred	
  Bovy	
  
	
  
	
  
Transitionn	
  to	
  IPv6	
  ...
Upcoming SlideShare
Loading in...5
×

Transition to ipv6 cgv6-edited

401

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
401
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transition to ipv6 cgv6-edited

  1. 1.     White  Paper   Service  Provider  Transition  to  IPv6:  NAT,  NAT64,   6RD,  DS-­‐LITE  and  Carrier  Grade  IPv6           Email:  fred@fredbovy.com      
  2. 2.   Service  Provider  Transition  to  IPv6   2     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       Table  of  Contents   1   Introduction:  Transition  Technologies  Needed  for  Decades  ........................................  3   2   Dual-­‐Stack  ..................................................................................................................  3   3   Network  Address  Translation  .....................................................................................  3   3.1   Network  Address  Translation  from  NAT  to  NPT6  ................................................................................  3   3.1.1   IPv4  to  IPv4  Translation:  NAT  or  NAT44  ..................................................................................................  3   3.1.2   IPv6  to  IPv6  Translation:  NAT66  to  NPT6  ................................................................................................  4   3.1.3   Network  Address  Translation  from  NAT-­‐PT  to  NAT464  ....................................................................  5   3.1.4   IPv4  to  IPv4  Translation:  Double  NAT  or  NAT444  ...............................................................................  5   4   Tunneling  ...................................................................................................................  8   4.1   IPv4  in  IPv6  Tunneling  +  NAT  (LSN):  DS-­‐Lite  .........................................................................................  8   4.2   IPv6  in  IPv4  Tunneling  ...................................................................................................................................  10   4.2.1   IPv6  in  IPv4  Static  Tunnels  ...........................................................................................................................  10   4.2.2   IPv6  in  IPv4  Automatic  Tunnels  .................................................................................................................  10   4.3   IPv6  in  IPv4  MPLS  Tunneling  ......................................................................................................................  12   5   Carrier  Grade  IPv6  (CGv6)  .........................................................................................  12   5.1   Network  Address  Translation  .....................................................................................................................  12   5.2   Tunneling.  ............................................................................................................................................................  12    
  3. 3.   Service  Provider  Transition  to  IPv6   3     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       1 Introduction:  Transition  Technologies  Needed   As  connected  devices  become  more  pervasive,  available  IPv4  addresses  decline  and   soon  will  be  completely  depleted.  IPv6  has  been  around  for  more  than  10  years  and   supported  by  most  operating  systems  and  network  vendors.  Despite  this,  most  service   providers  and  companies  have  not  transitioned  to  this  next  generation  Internet   protocol.  As  a  consequence,  more  time  is  needed  to  allow  a  smooth  transition  to  IPv6.   Because  of  this,  you  may  need  to  support  mixed  IPv4  and  IPv6  networks  for  a  few  more   years.   Maximum  performance,  security,  and  other  benefits    will  be  achieved  once  the  transition  to   IPv6  is  complete.  Meanwhile,  features,  performance,  and  security  will  have  to  be   compromised  in  order  to  support  IPv4  nodes  and  applications.   There  are  three  transition  methods:   -­‐ Dual-­‐stack   -­‐ Network  Address  Translation  (NAT44,  NAT64,  DNS64,  NAT444,  NAT464)   -­‐ Tunneling  (6rd,  DS-­‐Lite,  6PE,  6VPE)   This  paper  discusses  each.   2 Dual-­‐Stack   Dual-­‐stack  is  the  preferred  transition  method.  All  workstation  and  server  operating   systems  (Windows,  MAC,  Linux)  come  configured  as  dual-­‐stack  by  default.  When  a  host   needs  to  transmit  a  packet,  it  sends  a  DNS  Request  to  get  an  address.  If  the  DNS  reply   includes  both  IPv6  and  IPv4  addresses,  it  will  prefer  the  IPv6.  The  only  drawback  of  this   method  is  the  duplicated  effort  to  maintain  IPv4  and  IPv6  concurrently.  Also,  you  must   apply  the  same  level  of  security  to  both  protocols  or  you  may  risk  that  IPv4  will  be  used   to  discover  the  nodes  and  IPv6  will  be  used  to  breach  security  if  the  IPv6  security  is  not   as  strong  as  IPv4  security.   3 Network  Address  Translation   When  the  Internet  community  became  concerned  about  IPv4  address  depletion,  they   created  workarounds.  These  workarounds  included  classless  interdomain  routing   (CIDR)  or  variable-­‐length  subnet  masking  (VLSM)  to  save  addresses,  Dynamic  Host   Configuration  Protocol  (DHCP)  for  better  address  management,  and  Network  Address   Translation  (NAT).   3.1 Network  Address  Translation  from  NAT  to  NPT6   3.1.1 IPv4  to  IPv4  Translation:  NAT  or  NAT44     Introduced  in  the  mid-­‐90s  to  support  private  addressing,  NAT  and  NAT44  extended  the   life  of  IPv4  by  making  people  think  that  address  depletion  would  no  longer  be  an  issue.   However,  NAT  also  introduced  some  side  effects—both  good  and  bad.  RFC2993   discusses  the  architectural  implications,  advantages,  and  problems  of  NAT.  
  4. 4.   Service  Provider  Transition  to  IPv6   4     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       On  one  hand,  NAT  broke  the  end-­‐to-­‐end  IP  model.  Applications  that  must  be  supported,   like  DNS  or  FTP,  require  NAT  software  updates  (application  layer  gateway  [ALG]).  For   more  details  about  ALG,  see  RFC2663:  NAT  Terminology  and  Considerations.   When  an  inside  host  must  be  reachable  from  an  outside  public  space,  it  consumes  a   public  address  and  a  static  translation  must  be  configured.  Some  users  see  this  as  a   security  feature.  IPv4  firewalls  usually  do  NAT,  but  a  NAT  router  is  not  a  firewall!     Stateful  NAT  is  a  bottleneck,  a  single  point  of  failure,  and  can  be  the  target  of  denial  of   service  (DoS)  attacks.   On  the  other  hand,  with  NAT  and  private  addresses,  users  are  not  constrained  by  public   addresses  (address  independence).   NAT  also  permits  obscuring  the  end  user  network.  Hiding  topology  and  hosts  makes   some  people  think  that  NAT  is  an  important  security  feature.  For  these  reasons,  some   architects  will  not  consider  a  network  design  without  NAT!     RFC6092  provides  recommendations  for  implementing  security  in  an  IPv6  network.   This  document  also  differentiates  between  actual  security  and  the  features  of  NAT   gateways.   3.1.2 IPv6  to  IPv6  Translation:  NAT66  to  NPT6   With  the  introduction  of  IPv6  and  its  128-­‐bit  addresses,  NAT  was  no  longer  needed  to   provide  a  unique  address  to  Internet  users  and  the  end-­‐to-­‐end  IP  model  was  restored.   Larger  address  space  was  a  main  driver  for  IPv6.  The  introduction  of  NAT66  into  IPv6   was  a  frustration  for  IPv6  proponents.   In  addition  to  its  well-­‐known  problems,  NAT66  broke  the  security  implemented  by  IPSec   by  changing  the  IPv6  header.    But  proponents  of  NAT  did  not  like  that  NAT  benefits  were   missing  from  IPv6  and  also  argued  that  NAT  could  solve  the  multihoming  issue.  After   much  discussion  and  an  RFC  to  document  everything,  the  IETF  rejected  the  proposed   NAT66  drafts.   RFC5902  discusses  the  pros  and  cons  of  NAT66.  It  tries  to  justify  the  request  for  NAT66:     « 2. What is the problem? The discussions on the desire for IPv6 NAT can be summarized as follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security. » RFC4864  explains  IPv6  solutions  to  the  NAT66  claimed  benefits  without  requiring  any   address  translation.  NAT  supporters  were  not  deterred.    They  responded  by  developing   a  simplified  stateless  NAT66  that  was  renamed  Network  Prefix  Translation  or  NPT6,   which  was  approved  in  RFC6296.  
  5. 5.   Service  Provider  Transition  to  IPv6   5     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       3.1.3 Network  Address  Translation  from  NAT-­‐PT  to  NAT464   3.1.3.1 NAT-­‐PT  (RFC2766)   For  transitioning  to  IPv6,  Network  Address  Translator-­‐Protocol  Translator  (NAT-­‐PT)   was  the  first  protocol  translation  method  implemented  by  Cisco  IOS.   NAT-­‐PT  equates  to  NAT64  +  NAT46  +  ALG.   NAT64  is  the  NAT  translation  initiated  by  the  IPv6  side,  and  NAT46  was  initiated  by  the   IPv4  side.  NAT-­‐PT  was  the  answer  for  all  the  cases,  but  it  consumed  many  resources  and   IOS  running  NAT-­‐PT  was  process  switching  with  the  very  low  performances  we  know.   Use  of  NAT-­‐PT  is  now  deprecated  (RFC4966).   3.1.3.2 NAT64/DNS64   3.1.3.2.1 What  is  the  problem  we  want  to  solve?   Workstations  run  dual-­‐stack  by  default.  Equipment  using  Windows,  MAC  OS,  and  Linux   operating  systems  is  set  up  with  dual  stack  by  default.  It  is  not  difficult  to  upgrade  a   workstation  if  it  runs  an  old  operating  system  without  dual  stack.  From  the  initialization   side,  IPv6  support  is  not  the  problem.  On  the  other  hand,  it  may  be  more  difficult  to   upgrade  an  application  to  support  IPv6.     3.1.3.2.2 DNS64  (RFC6147)   NAT64  relies  on  DNS64  to  manage  the  DNS  request  and  send  a  reply  to  the  source  with   an  IPv6  prefix  built  from  the  IPv4  address  received  from  the  target  node.  DNS64  first   sends  a  request  for  a  AAAA  prefix.  If  it  receives  an  error,  it  then  tries  to  ask  an  A  prefix.   Then  if  it  receives  an  answer,  DNS64  converts  it  to  a  AAAA  IPv6  prefix.   This  IPv6  address  is  built  using  a  NAT64  well-­‐known  prefix  (64:FF9B::/96)  followed  by   the  IPv4  address  coded  as  an  IPv6  address.  The  A  record  with  193.45.5.1  address  will  be   converted  to  the  AAAA  record  with  64:FF9B::193.45.5.1  or  64:FF9B::C12D:501  address.   3.1.3.2.3 Stateless  or  Stateful  NAT64   The  packet  from  the  source  is  routed  to  the  NAT64  box  using  the  normal  IPv6  routing.   The  NAT64  box  translates  the  IPv6  packet  to  an  IPv4  packet  and  sends  it  to  the  target.  It   also  performs  the  opposite  when  the  answer  comes  back  from  the  IPv4  host.   NAT64  can  be  stateless  (see  RFC6052)  or  stateful  (see  RFC6145,  RFC6146  and   RFC6052).  Stateless  means  that  an  IPv4  address  is  needed  for  each  translated  IPv6   address.  Stateful  is  required  if  multiple  IPv6  addresses  must  map  to  the  same  IPv4   address.   3.1.4 IPv4  to  IPv4  Translation:  Double  NAT  or  NAT444   NAT  at  the  CPE  has  already  permitted  to  IPv4  to  last  for  20  more  years  and  now  the  ISPs   are  starting  to  use  NAT  one  more  time  at  the  next  level  with  NAT444.  NAT444  refers  to   double  NAT,  where  NAT44  is  performed  a  first  time  by  the  CPE  at  the  customer’s  site   and  then  a  second  time  by  the  service  provider.  Carrier-­‐grade  NAT  (CGN)  and  large-­‐ scale  NAT  (  LSN)  refer  to  NAT  running  at  the  service  provider  instead  of  the  CPE.  
  6. 6.   Service  Provider  Transition  to  IPv6   6     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012         Figure  1.  NAT  444   A  device  in  a  customer  network  might  send  a  packet  to  an  Internet  destination  with  a   source  address  of  10.1.1.1.  The  CPE  NAT  translates  the  source  address  to,  for  example,   172.16.1.1  with  accompanying  port  mapping.  At  the  LSN,  the  source  address  is   translated  to  the  public  IPv4  address,  say  201.15.83.1  again  with  port  mapping,  and  the   packet  is  routed  to  the  destination.  Responding  packets  to  201.15.83.1  are  routed  to  the   service  provider’s  aggregate  IPv4  address,  then  to  the  appropriate  LSN,  which  translates   the  destination  address  back  to  172.16.0.1  and  forwards  the  packet  to  the   corresponding  CPE  NAT,  which  translates  the  destination  address  to  10.1.1.1.   This  looks  simple,  but  this  design  is  not  without  issues.   One  issue  is  scalability.  Behind  the  CPE,  the  customer  may  be  running  many  devices.   Each  device  may  generate  many  data  streams.  There  is  not  yet  enough  production   experience  to  know  the  upper  boundaries  of  how  many  customer  networks  a  single  LSN   can  manage,  either  in  terms  of  performance  or  in  terms  of  mapping  steams  to  a  single   public  IPv4  address.     Also,  it  becomes  impossible  to  track  a  user  using  its  IP  address.  If  a  new  application   requires  an  ALG,  it  must  be  installed  by  the  SP.   Another  issue  is  the  possibility  of  address  overlaps  between  the  customer’s  network  and   the  private  addresses  used  by  the  service  provider.  For  example,  if  the  provider  uses   addresses  out  of  the  172.16.0.0/12  block  between  the  LSN  and  the  CPE  NAT,  and  the   customer  addresses  his  network  out  of  the  same  block,  uniqueness  between  the  two   zones  is  lost  and  packets  might  be  misrouted.  Insuring  that  customers  use  non-­‐ conflicting  address  ranges  can  be  an  administrative  headache  for  the  provider.  
  7. 7.   Service  Provider  Transition  to  IPv6   7     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012             Figure  2.  Firewall  Blocks  Packets  with  Private  Source  Address     Yet  another  issue  occurs  when  a  customer  wants  to  send  packets  to  another  customer   behind  the  same  LSN.  Filtering  policies  in  firewalls,  router  ACLs,  and  even  servers  often   block  packets  from  outside  the  network  that  have  private  source  addresses.  To   circumvent  this  problem,  packets  must  pass  through  the  LSN  so  that  their  source   addresses  can  be  translated  to  a  public  address  and  then  switched  back  through  the  LSN   to  the  destination.  LSN  resources  are  consumed  even  though  the  packets  are  not  going   to  a  destination  beyond  the  LSN.   A  proposed  solution  to  these  problems  is  to  reserve  a  block  of  the  remaining  public  IPv4   space  as  an  “ISP  shared  address”  space.  Because  the  address  block  would  be  reserved   for  use  in  NAT444  architectures,  the  same  addresses  can  be  used  behind  different  LSNs   the  same  way  RFC1918  addresses  are  used  for  private  networks.  Because  the  address   would  not  be  RFC1918  addresses,  they  would  not  conflict  with  the  private  addresses  in   any  customer  network.  Also  because  they  are  not  RFC1918  addresses,  filtering  policies   will  not  block  them.  Packet  flows  between  customers  behind  the  same  LSN  will  not  have   to  pass  through  the  LSN.   Another  solution  is  to  use  IPv6  on  the  CPE  NAT-­‐to-­‐LSN  link;  this  is  NAT464.  It  will  go  in   the  good  direction  with  IPv6  between  the  customer  and  the  service  provider.  
  8. 8.   Service  Provider  Transition  to  IPv6   8     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       3.1.4.1 NAT464   A  problem  with  this  design  is  that  now  the  CPE  must  perform  NAT46  address   translation  instead  of  NAT44.  This  design  will  require  upgrading  all  the  CPEs,  which  is   an  expensive  solution.     Figure  3.  NAT464   4 Tunneling   There  are  a  few  choices  for  encapsulating  IPv4  in  IPv6,  IPv6  in  IPv4,  or  IPv6  in  MPLS   IPv4.   4.1 IPv4  in  IPv6  Tunneling  +  NAT  (LSN):  DS-­‐Lite   Because  all  customers  will  not  migrate  at  once  to  IPv6,  a  big  problem  for  service   providers  is  supporting  RFC1918  IPv4  customers  after  the  backbone  has  migrated  to   IPv6.    Dual  Stack  Lite  (DS-­‐Lite)  solves  this  with  IPv4  in  IPv6  tunneling  and  NAT44.   Another  problem  is  that  all  the  applications  will  not  migrate  to  IPv6  at  once  either  and   the  clients  will  need  to  run  IPv4  and  dual-­‐stack  for  a  while  to  access  the  IPv4  servers.   DS-­‐Lite  will  permit  this.   DS-­‐Lite  uses  the  IPv6  source  address  of  the  tunnel  with  the  IPv4  source  address  and  the   source  port  number  to  identify  each  tunnel  source  endpoint.  Without  this,  there  would   be  no  way  to  differentiate  two  overlapping  customers  using  the  same  RFC1918  private   address.    
  9. 9.   Service  Provider  Transition  to  IPv6   9     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012           Figure  4.  DS-­‐Lite  IPv4  in  IPv6  Tunnel     Figure  5.  DS-­‐Lite  =  IPv4  in  IPv6  Tunnel  +  LSN  
  10. 10.   Service  Provider  Transition  to  IPv6   1 0     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012         Figure  7.  IPv6  Routed  Directly.  IPv4  Routed  to  LSN.   4.2 IPv6  in  IPv4  Tunneling   IPv6  in  IPv4  was  the  first  overlay  tunnel  used  during  the  transition  to  IPv6.  The  first   experimental  IPv6  network,  the  6BONE,  was  created  from  overlay  tunnels  connecting   IPv6  islands  across  the  IPv4  Internet.     IPv6  in  IPv4  tunnels  can  be  statically  or  automatically  configured.   4.2.1 IPv6  in  IPv4  Static  Tunnels   For  IPv6  in  IPv4  static  tunnels  or  6in4  static,  you  must  configure  the  tunnel  source  and   destination  IPv4  addresses.  This  is  the  least  unsecure  option  as  you  can  control  the   source  and  destination  of  the  tunnel.  If  possible,  use  IPSec  to  secure  these  tunnels.   4.2.2 IPv6  in  IPv4  Automatic  Tunnels   With  automatic  tunnels,  you  don’t  need  to  configure  the  IPv4  destination  of  the  tunnel.   Automatic  tunnels  also  provide  IPv6  addressing.  Teredo  and  Intra-­‐Site  Automatic   Tunnel  Addressing  Protocol  (ISATAP)  automatic  tunnels  are  not  intended  for  service   providers  and  are  not  discussed  here.   4.2.2.1 6to4:  The  Origin  (RFC3056)   The  first  popular  automatic  tunnels  were  6to4.  These  tunnels  solved  two  problems:  IPv6   addressing  and  automatic  destination  tunnel  configuration.  They  provided  the  reserved   IPv6  prefix—2002::/16.  Following  this  prefix  was  the  6to4  gateway  public  IPv4   address.    This  way,  the  destination  IPv4  address  of  the  tunnel  was  coded  in  the  
  11. 11.   Service  Provider  Transition  to  IPv6   1 1     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       destination  IPv6  address.  For  instance,  if  a  6to4  gateway  public  IPv4  address  was   193.2.4.5,  the  IPv6  site  that  would  be  reachable  from  this  6to4  gateway  would  use  the   prefix  2002:193.2.4.5::/48  or  2002:c102:405::/48.   Microsoft  provided  6to4  relays  on  the  Internet  using  the  IPv4  anycast  address   192.88.99.1  for  anyone  using  6to4  to  have  access  to  the  IPv6  Internet  from  IPv4.   For  ISPs,  the  biggest  problem  with  6to4  is  the  lack  of  flexibility  due  to  the  fixed   2002::/16  prefix.  6to4  also  lacks  basic  security  features  (RFC3964).   6to4  is  now  deprecated.         4.2.2.2 6rd:  The  Next  Generation  (RFC5969)   Free  Telecom,  a  French  ISP,  customized  the  code  of  a  6to4  platform  to  accept  any  ISP   prefix  instead  of  2002::/16  and  provided  instant  IPv6  access  to  their  customers.  They   provided  the  relays  to  access  the  IPv6  Internet  and  called  this  6rd  for  IPv6  Rapid   Deployment.  6rd  became  the  de  facto  standard  for  service  providers  with  an  IPv4   backbone  to  provide  IPv6  service  to  their  customers.   6rd  was  implemented  in  Cisco  IOS  Software  Release  15.1(3)T  and  is  documented  in   RFC5969.     Figure  6.  6rd,  6to4  with  a  Customized  Prefix      
  12. 12.   Service  Provider  Transition  to  IPv6   1 2     Fred  Bovy       Transitionn  to  IPv6     22/08/11  2:03  PM   fred@fredbovy.com   Fred  Bovy  EIRL  –  Ipv6  For  Life!  ©  2012       4.3 IPv6  in  IPv4  MPLS  Tunneling   For  service  providers  with  an  IPv4  MPLS  backbone,  the  transition  methods  are  IPv6   Provider  Edge  Router  (6PE)  and  IPv6  VPN  Provider  Edge  Router  (6VPE).   6PE  is  for  the  transport  of  IPv6  on  top  of  MPLS  IPv4.  6VPE  adds  the  support  of  IPv6  in   MPLS-­‐VPN.  The  VRF  can  be  dual-­‐stack.  Both  are  stable,  efficient,  and  scalable  methods  to   provide  IPv6  services  over  an  IPv4  MPLS  backbone.   While  6PE  and  6VPE  are  important  transition  methods  for  service  providers,  they  are   not  discussed  in  this  white  paper.   5  Carrier  Grade  IPv6  (CGv6)   CGv6  is  the  Cisco  solution  to  support  service  providers  during  the  transition  to  IPv6.   CGv6  runs  on  a  dedicated  carrier-­‐grade  service  engine  on  the  CRS-­‐1.  CGv6  is  also   available  on  Cisco  ASR  9000  with  IOS-­‐XR  and  Cisco  ASR  1000  with  Cisco  IOS-­‐XE   Software.   5.1 Network  Address  Translation   CGv6  supports  double  NAT444  where  NAT44  is  performed  at  the  CPE  and  again  at  the   service  provider.  CGv6  also  supports  Address  Family  Translation  or  IVI,  which   represents  the  Roman  numerals  for  4  (IV)  and  6  (VI);  in  other  words,  NAT46  and   NAT64.   5.2 Tunneling.   CGv6  supports  6rd  and  DS-­‐Lite.   For  more  information  about  the  Cisco  CGv6  solution,  visit   http://www.cisco.com/go/cgv6  and  http://www.ccmi.com/IPv6/Cisco_CGv6.pdf                   Fred BOVY, CCIE #3013 fred@fredbovy.com

×