[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]