[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] V6DH - IPv6 Dual-Homing



[repost with corrected subject]

I've finally put my proposal down on "paper". (Attached in ID
format.)

I'll upload it to the wiki site as well, as soon as IDs are able to be submitted at tools.ietf.org again (posting not possible until after philly).

Comments are certainly welcome - it's a first draft, and I might have
missed some obvious problem areas.

Brian Dickson





rrg                                                           B. Dickson
Internet-Draft                                       Afilias Canada, Inc
Expires: September 4, 2008                                 March 3, 2008


  V6DH: Incremental IPv6 Dual-Homing Approach for addressing end-site
            reliability needs (per RADIR problem statement)
                       draft-dickson-rrg-v6dh-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Dickson                 Expires September 4, 2008               [Page 1]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


Abstract

   This Internet Draft describes .

   FIXME














































Dickson                 Expires September 4, 2008               [Page 2]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


Author's Note

   This Internet Draft is intended to result in this draft or a related
   draft(s) being placed on the Standards Track for rrg.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   Intended Status: Proposed Standard.


Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Addressing Convention - Format . . . . . . . . . . . .  4
       1.1.2.  FIB/host lookup changes  . . . . . . . . . . . . . . .  5
       1.1.3.  DNS tweaks for sites/hosts . . . . . . . . . . . . . .  5
       1.1.4.  Edge reachability  . . . . . . . . . . . . . . . . . .  6
     1.2.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
   2.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15






















Dickson                 Expires September 4, 2008               [Page 3]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


1.  Background

   The RADIR problem statement summarizes requirements for new solutions
   to the pressure under which the routing system for IPv4 and IPv6
   finds itself, particularly in the DFZ.

   By ignoring the issue in IPv4 and presenting a solution that fits
   well with the existing routing infrastructure and routing protocols
   for IPv6, this proposal hopes to bypass deficiencies and trade-offs
   of solutions which attempt to solve both IPv6 and IPv4 routing
   growth.

   This deliberate choice may be best understood by comparing the
   resulting design with other solutions within the IPv6 space only, and
   considering that son-of-NAT-PT may be sufficient for IPv4 legacy
   needs.

1.1.  Proposal

   The central element of this proposal is the use of a new addressing
   CONVENTION.

   Rather than creating a new addressing space that is not routed (LISP
   use of EIDs), or any other new addressing mechanism, this involves
   the assignment of special addresses within one PA assignment, which
   corresponds to the other PA assignment for a dual-homed site.

   Consequently, the addresses used in V6DH are always routable, and all
   the rest of the proposal elements are effectly optimizations, on
   performance and reliablity.  Some of the additional proposal elements
   are similarly new conventions on how to make use of existing
   mechanisms (e.g.  DNS), and do not require changes to third party
   equipment for the end site to realize some benefits.

   Of course, the full set of benefits are best seen upon universal
   deployment.  However, the small scope of the changes, and the fact
   that some changes can be done in more than one place topologically
   speaking, means that the incentives are likely to outweigh the
   incremental cost.

1.1.1.  Addressing Convention - Format

   Given two upstream PA assignments PA-A and PA-B, whose format is:








Dickson                 Expires September 4, 2008               [Page 4]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


   +-------- PA-A --------+ subnet-bits-A +--------------|
   + 'a' bits -+ 'b' bits +- 'c' bits ----+--- 64 bits --|
   | RIR block |  PA-net  | subnet bits   | Interface ID |
   +-----------+----------+---------------+--------------|

   where a+b+c = 64; note that 'c' may be 0 (zero) bits long.

                                 Figure 1

   New address range "subnets" within those blocks are constructed as:

   +------+---------------+------+---------------|
   | PA-A | subnet-bits-A | PA-B | subnet-bits-B |
   +------+---------------+------+---------------|

   and/or

   +------+---------------+------+---------------|
   | PA-B | subnet-bits-B | PA-A | subnet-bits-A |
   +------+---------------+------+---------------|

                                 Figure 2

   The general format semantics is Primary + Secondary, as the Primary
   will normally be used for routing if the Primary destination is
   perceived by intermediate sites as reachable.

   Those addresses may or may not be transformed via 1:1 NAT onto end
   host addresses by the site's infrastructure (e.g. edge routers).

1.1.2.  FIB/host lookup changes

   If either the host, or any router in the path (ideally the first
   router, but conceptually any router) determines that the destination
   is unreachable, the IP destination SHOULD be modified by swapping the
   first 64 bits with the last 64 bits.  This SHOULD ONLY be performed
   if the last 64 bits are determined to be a feasible destination
   (either by the host, comparing the last 64 bits to the value
   2000::/3, or by the router, checking its FIB for a valid next hop).

1.1.3.  DNS tweaks for sites/hosts

   DNS servers SHOULD be advertised from an end site with addresses from
   both PA-A and PA-B blocks.  There is no requirement that they be
   addressed via the new convention, and in fact doing so would make
   server addresses no longer a Class 1 object.  As such, DNS servers
   SHOULD NOT be addressed via the proposed convention.




Dickson                 Expires September 4, 2008               [Page 5]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


   End addresses of hosts MAY be served with the new convention.  When
   hosts' addresses are served from DNS via AAAA records using the new
   convention, the current state of reachability SHOULD be updated via
   dynamic DNS.  This reduces load on hosts and routers doing address
   swapping.  DNS TTL values SHOULD be chosen appropriately low for such
   AAAA records.  DNS TTL values for the zone cuts facing the DNS
   servers serving up such AAAA records SHOULD be in line with best
   current practices for operating DNS zones.

1.1.4.  Edge reachability

   There are two methods of determining reachability.  Host behavior is
   nearly trivial to implement.  Routing announcments are a new
   dependency for improving performance and scalability of this
   solution.

1.1.4.1.  Edge reachability - host behaviour

   Hosts SHOULD track connection reachability by use of ICMP
   unreachables.  If a destination is determined to be reachable, based
   on receipt of either host or network unreachable ICMP message, then
   the address modification method described above should be employed.

1.1.4.2.  Edge reachability - routing announcements

   Rather than having a Mapping Table which scale by the number of
   multi-homed sites, this proposal eventually requires (for scalability
   reasons) a table of "unreachable" end-site prefixes.

   The information about how a site is connected (PA-A and PA-B) is
   separated from the status of the links for provider A and provider B.

   This means that the table scales by the number of links that are
   currently out of service, rather than by the number of links.  This
   is anticipated to be, as a general rule, three or four orders of
   magnitude smaller.

   Furthermore, when widespread outages occur, they are expected to be
   localized topologically (e.g. an ISP with a major outage), and the
   unreachabilty information MAY be aggregated by ISPs.

1.1.4.2.1.  New BGP AFI/SAFI - LinkDown

   Within BGP-4, the term "unreachable" normally refers to the
   "withdrawal" of a previously announced prefix.

   However, the unreachability we need information on is the more-
   specific link status, which is normally hidden by the very



Dickson                 Expires September 4, 2008               [Page 6]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


   aggregation that make PA blocks scale well.

   This information is not needed in the DFZ itself, only at the edges.
   As such, it is appropriate to carry it in an opaque manner, as a new
   AFI/SAFI type.

   Details on this to be developed separately within IDR WG.

1.1.4.2.1.1.  Details of LinkDown Behavior

   When a network is performing BGP aggregation, it normally supppresses
   the more-specific prefixes.  The change in behavior proposed, is that
   when such more-specific prefixes "flap", that this unavailablity
   information be passed as a LinkDown BGP SAFI, across the DFZ (without
   impacting DFZ FIBs), to the sending-side edge router(s).  This
   information is used to trigger not only this proposed Dual-Homing
   mechanism, but for any destinations not structured per the
   convention, to discard packets that would not be delivered (because
   the destination is unreachable) at the ingress side.

   This provides immediate benefit to the ISP, to support this new BGP
   AFI/SAFI, and provides a scalable, standardized means of implementing
   "black-holing" of traffic.

1.1.4.2.1.2.  Routing Topology Recommended for LinkDown peering

   Since the main component of the LinkDown is the prefix, and since it
   is expected to be announced by the originator of the BGP aggregate
   covering the prefix, there are good reasons to pass this information
   along the same topology as regular BGP-4+ prefix information.


   o  The more-specific information is likely to be subject to the same
      filtering policies

   o  The trust relationship among peers, and contractual relationships,
      best supports use of the same paths for LinkDown information

   o  The exclusion of the LinkDown information from the DFZ, and its
      absence from the generalized FIBs of some or most intermediate
      ASNs, means that different BGP-4+ peers may be used for carrying
      LinkDown prefixes, with no ill effects.

   o  Further optimizations by implementing multi-hop peering for
      sharing LinkDown information are possible, e.g. where such multi-
      hop peering would not be appropriate for IPv6 prefixes for normal
      NLRI information.




Dickson                 Expires September 4, 2008               [Page 7]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


   o  The fact that no next-hop is needed (and is implicitly Null0), the
      LinkDown "FIB" can be remarkably small.

1.2.  Analysis

   Summary:

   o  Simple - to understand, to implement on hosts, to deploy at sites

   o  Cheap - and can even (marginally) reduce transit costs by dropping
      unreachable destination packets sooner

   o  Skinny - when deployed on routers, no host changes needed; router
      changes close to trivial on FIB side

   o  E2E - fully interoperable and backwards compatible (e.g. when both
      links are up)

   o  E2E - destination-only

   o  Modular - can be deployed in multiple places in a path, first hop
      with implemented preempts later hops

   o  Good Enough - does not preclude other mechanisms for later
      deployment

   o  Minimizes Options - "activated" entirely by end site with no
      intervention needed elsewhere (modulo LinkDown support by ISPs)

   o  Consistent - easy to recognize its use, doesn't affect DFZ at all

   o  Scalable - no DFZ impact, edge "mapping" three to four (or more)
      orders of magnitude smaller than map-encap schemes

   o  Performance - typically in hardware, would require O(1) extra
      lookups (e.g. where N=1, O(N) is by definition 1)

   o  Zero overhead on forwarding path - only 64/64 bit IP header swap,
      no change to packet size - no MTU issues, no fragmentation

   o  No dependency on DNS - but supports use of DNS to further enable
      early adoption with even lower barrier to deployment

   o  Supports limited end-site Traffic Engineering (choice of primary/
      secondary)

   o  Completely compatible with ISP Traffic Engineering - no change to
      addressing within PA blocks



Dickson                 Expires September 4, 2008               [Page 8]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


   o  As secure as BGP - and benefits from any new BGP security
      developments

   o  Facilitates renumbering/rehoming - renumbering is still needed,
      but is well scoped and avoids "flag day" issues

   o  No "Stretch" introduced

   o  No DFZ convergence issues introduced

   o  Edge convergence likely limited to propagation time, due to order-
      of-magnitude of edge link outages compared with number of edge
      links

   o  Dynamic-DNS and double addressing can already be deployed, and
      achieves most of the initial benefits



































Dickson                 Expires September 4, 2008               [Page 9]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


2.  Security Considerations

   No additional security considerations beyond those already present in
   BGP are introduced.















































Dickson                 Expires September 4, 2008              [Page 10]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


3.  IANA Considerations

   IANA may need to assign new code points for BGP Address Family and/or
   Subsequent Address Family (AFI/SAFI).















































Dickson                 Expires September 4, 2008              [Page 11]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


4.  Acknowledgements

   The author wishes to acknowledge the helpful guidance of Joe Abley,
   Tony Li, and Yakhov Rehkter.















































Dickson                 Expires September 4, 2008              [Page 12]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


5.  References

5.1.  Normative References

5.2.  Informative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.











































Dickson                 Expires September 4, 2008              [Page 13]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


Author's Address

   Brian Dickson
   Afilias Canada, Inc
   4141 Yonge St,
   Suite 204
   North York, ON  M2P 2A8
   Canada

   Email: brian.peter.dickson@gmail.com
   URI:   www.afilias.info








































Dickson                 Expires September 4, 2008              [Page 14]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Dickson                 Expires September 4, 2008              [Page 15]