Re: [GLOBAL-V6]IPv6 Allocation Policy

  • To: "Craig A. Huegen" <chuegen at cisco dot com>
  • Subject: Re: [GLOBAL-V6]IPv6 Allocation Policy
  • From: Pekka Savola <pekkas at netcore dot fi>
  • Date: Thu, 22 May 2003 08:26:44 +0300 (EEST)
  • Cc: Brian E Carpenter <brian at hursley dot ibm dot com>, <global-v6 at lists dot apnic dot net>
  • In-reply-to: <Pine.WNT.4.44.0305211404490.936-100000 at chuegen-w2k04.amer dot cisco dot com>
  • List-archive: <>
  • List-help: <>
  • List-id: Discussion of new global IPv6 policy development <>
  • List-post: <>
  • List-subscribe: <>,<>
  • List-unsubscribe: <>,<>
  • Sender:
    • > > So, it seems to me that Cisco would be best using multiple ISP-specific PA
      > > addresses, right?  That would seem to solve about all the problems related
      > > to traffic engineering?  (You only configure addresses of those ISP's
      > > which are connected to your public service sites -- and each of them gets
      > > there without WAN traffic.)
      > Actually, it would not.
      > Multiple PA prefixes as a solution has far too many problems.
      Certainly, one can argue that it has far too many problems for any kinds 
      of networks.
      > I as a
      > network administrator cannot control the traffic flow -- originating hosts
      > get to set the network paths by their choices of source/destination
      > addresses.
      You cannot control the source addresses the hosts pick anyway *).  The
      only way you could meaningfully influence it would be via having a single
      destination prefix for each region-specific service in the DFZ.  And as
      the BGP path selection is not as good as it could be, even that is shaky.  
      So, I think you need the off-band mechanisms to optimize this (e.g.  
      cookies to store the location + HTTP redirection).
      If a service located e.g. in Australia has IP addresses from two 
      Australian ISPs only, I would wager to guess the traffic flow is rather 
      optimal in that region.
      *) this is another thing RIR's+IANA have been incredibly stupid about,
      much less stingy to a harmful degree: come on, with one IANA /23
      allocation, you can only make 64 "sTLA" allocations.  If IANA had given
      each RIR e.g. a /16, the longest-prefix match might have resulted in
      useful results so that when destination has addresses from RIPE and ARIN
      region, the source who is in ARIN region might have chosen the ARIN
      destination... but NO.
      > I have to manage extra prefixes on
      > every subnet and carry those multiple prefixes in my IGP.  
      Only those subnets where you have services would be critical: not too many 
      I think.
      > A failure of a
      > circuit at the edge of the network would trigger an amazingly huge
      > state-change wave across the network, 
      Which edge?  I assume you mean the edge between a regional ISP and a 
      regional office, not the edge to your subnets.
      > withdrawing the prefixes from the
      > interface, then removing them from the IGP.
      I would hope that a change like this would be topologically regional (and
      thus not such a big deal), or otherwise I'd worry whether it's useful to 
      spread the information further away than necessary.
      > There are just too many problems in a large network like ours to use the
      > multi-PA solution.
      Many say that, and I kind of agree to an extent, but this has never been 
      fleshed out... and as you seem most worried about the services and not 
      having to haul it across the WAN, I think those could be manageably 
      enabled in multi-PA fashion, at least.
      Pekka Savola                 "You each name yourselves king, yet the
      Netcore Oy                    kingdom bleeds."
      Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings