Subject: Question about past advice to RIRs

From: Fred Baker <[email-masked]>
Date: Mon, 7 Aug 2006 10:26:35 -0700

As discussed in the recent IETF meeting, Marla Azinger and I are  
putting together a document on IPv6 multihoming. My current list of  
references for the document includes the attached. Some of the  
reviewers have stated that at least some of the documents should be  
considered out of date.

If so, I think the IESG should advise the RFC Editor to mark them  
"historical".

In any event, would people please look through this and tell me which  
documents to drop?

Note that RFCs 1265, 1787, 2008, 2827, and 3704 are included for the  
perspectives they present whether currently applicable or not. The  
biggest problems seem to arise from RFCs 1881 and 1887; if they are  
obsolete, I have an entire section that might disappear.

7.  References

7.1.  Normative References

    [RFC2008]  Rekhter, Y. and T. Li, "Implications of Various Address
               Allocation Policies for Internet Routing", BCP 7,
               RFC 2008, October 1996.

    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

    [RFC3177]  IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
               Allocations to Sites", RFC 3177, September 2001.

    [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
               Delegation", RFC 3769, June 2004.

    [RFC4177]  Huston, G., "Architectural Approaches to Multi-homing for
               IPv6", RFC 4177, September 2005.

    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.

7.2.  Informative References

    [I-D.narten-ipv6-3177bis-48boundary]
               Narten, T., "IPv6 Address Allocation to End Sites",
               draft-narten-ipv6-3177bis-48boundary-02 (work in
               progress), June 2006.

    [I-D.white-sobgp-architecture]
               White, R., "Architecture and Deployment Considerations  
for
               Secure Origin BGP (soBGP)",
               draft-white-sobgp-architecture-02 (work in progress),
               June 2006.

    [METRO]    Deering, S., "Metro-Based Addressing", July 1995, <ftp://
               ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/
               presentations/allocation/deering.slides.ps>.

    [RFC1265]  Rekhter, Y., "BGP Protocol Analysis", RFC 1265,
               October 1991.

    [RFC1517]  Hinden, R., "Applicability Statement for the
               Implementation of Classless Inter-Domain Routing (CIDR)",
               RFC 1517, September 1993.

    [RFC1518]  Rekhter, Y. and T. Li, "An Architecture for IP Address
               Allocation with CIDR", RFC 1518, September 1993.

    [RFC1519]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
               Inter-Domain Routing (CIDR): an Address Assignment and
               Aggregation Strategy", RFC 1519, September 1993.

    [RFC1787]  Rekhter, Y., "Routing in a Multi-provider Internet",
               RFC 1787, April 1995.

    [RFC1881]  Internet Architecture Board and Internet Engineering
               Steering Group, "IPv6 Address Allocation Management",
               RFC 1881, December 1995.

    [RFC1887]  Rekhter, Y. and T. Li, "An Architecture for IPv6 Unicast
               Address Allocation", RFC 1887, December 1995.

    [RFC2073]  Rekhter, Y., Lothberg, P., Hinden, R., Deering, S.,  
and J.
               Postel, "An IPv6 Provider-Based Unicast Address Format",
               RFC 2073, January 1997.

    [RFC2374]  Hinden, R. and S. Deering, "An IPv6 Aggregatable Global
               Unicast Address Format", RFC 2374, July 1998.

    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
               Defeating Denial of Service Attacks which employ IP  
Source
               Address Spoofing", BCP 38, RFC 2827, May 2000.

    [RFC3178]  Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
               Site Exit Routers", RFC 3178, October 2001.

    [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
               Unicast Address Format", RFC 3587, August 2003.

    [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for  
Multihomed
               Networks", BCP 84, RFC 3704, March 2004.

    [RFC4076]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
               Requirements for Stateless Dynamic Host Configuration
               Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.

    [RFC4218]  Nordmark, E. and T. Li, "Threats Relating to IPv6
               Multihoming Solutions", RFC 4218, October 2005.

---

From: [email-masked]
Date: Mon, 7 Aug 2006 18:55:23 +0000

>               Address Allocation", RFC 1887, December 1995.

	note that both of these documents predate most of the RIR existance,
	when the IETF had a direct role in defining allocation policies/stratagies.

	in todays environment, i would consider both of these documents to be
	historical in nature, e.g. not applicable to the current RIR models.
	it is useful to note that RFC 1887 is labled "An Architecture..."
	which is a clear indication that the authors did not preclude other
	valid architectural models.

--bill

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 8 Aug 2006 11:35:24 +0200

On 8 aug 2006, at 11.15, Brian E Carpenter wrote:

> [email-masked] wrote:
>>> Note that RFCs 1265, 1787, 2008, 2827, and 3704 are included for  
>>> the  perspectives they present whether currently applicable or  
>>> not. The  biggest problems seem to arise from RFCs 1881 and 1887;  
>>> if they are  obsolete, I have an entire section that might  
>>> disappear.
>>>
>>>
>>> 7.  References
>>>
> You're overlooking that RFC 1881 was and remains the basis on which  
> the
> IPv6 address space was formally delegated to IANA by the community  
> that
> created it. There's no sense in which that delegation is historical.
> Certainly we have learned a thing or two since 1995.
>
> On a point of fact, the RIPE-NCC was established in 1992. It was  
> certainly
> my assumption in 1995 that IANA would further delegate prefixes to
> the registries, and that the registries would remain active in the
> IETF, so that address assignment practices would inform and be  
> informed
> by IETF discussions. That still seems to be happening, fortunately.

1881 even mentions the RIRs so I think that is still valid. 1887  
seems to be interesting reading I don't really think it reflects the  
network of today...

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Aug 2006 11:15:32 +0200

> 	valid architectural models.

You're overlooking that RFC 1881 was and remains the basis on which the
IPv6 address space was formally delegated to IANA by the community that
created it. There's no sense in which that delegation is historical.
Certainly we have learned a thing or two since 1995.

On a point of fact, the RIPE-NCC was established in 1992. It was certainly
my assumption in 1995 that IANA would further delegate prefixes to
the registries, and that the registries would remain active in the
IETF, so that address assignment practices would inform and be informed
by IETF discussions. That still seems to be happening, fortunately.

     Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 8 Aug 2006 11:51:22 +0200

On 7 aug 2006, at 19.26, Fred Baker wrote:

> In any event, would people please look through this and tell me  
> which documents to drop?
>
> the perspectives they present whether currently applicable or not.  
> The biggest problems seem to arise from RFCs 1881 and 1887; if they  
> are obsolete, I have an entire section that might disappear.

A quick review gives me the thoughts as below...I am sure I have  
overlooked some details...

>               Allocation Policies for Internet Routing", BCP 7,

AFAIK ok.

>               (IPv6) Specification", RFC 2460, December 1998.

AFAIK ok.

>               Allocations to Sites", RFC 3177, September 2001.

This is under discussion in draft-narten-ipv6-3177bis-48boundary-02  
as mentioned below.

>               Delegation", RFC 3769, June 2004.

AFIAK ok.

>               IPv6", RFC 4177, September 2005.

AFAIK ok.

>               Architecture", RFC 4291, February 2006.

AFAIK ok.

>               White, R., "Architecture and Deployment  
> Considerations for

Not IETF docs per se.

>    [RFC1265]  Rekhter, Y., "BGP Protocol Analysis", RFC 1265,

This analysis applies to BGPv3. Some of the conclusions seems to  
hold,  but numbers and terminology might not. Should probably be  
updated rather than moved to historic.

>               RFC 1517, September 1993.

Seems ok.

>               Aggregation Strategy", RFC 1519, September 1993.

ok.

>    [RFC1787]  Rekhter, Y., "Routing in a Multi-provider Internet",

This is an informational document by the IAB to stimulate discussion  
at the time.

>               Steering Group, "IPv6 Address Allocation Management",

AFAIK ok.

>               Address Allocation", RFC 1887, December 1995.

Should preferable be updated or moved to historic. Not sure if there  
is value in updating it.

>               Postel, "An IPv6 Provider-Based Unicast Address Format",

Should be moved to historic (I thought it was when TLAs where taken  
out with RFC4291 (or actually 31513 I guess). It's at least been  
replaced with the IANA IPv6 unicast address registry.

>               Unicast Address Format", RFC 2374, July 1998.

Says it replaces 2073 so there seems to be some inconsistency....

>               Address Spoofing", BCP 38, RFC 2827, May 2000.

Updated by RFC3704, which is referenced below.

>               Site Exit Routers", RFC 3178, October 2001.

Don't believe this has ever been implemented but that doesn't mean  
it's historic.

>               Unicast Address Format", RFC 3587, August 2003.

AFIK ok.

>               Networks", BCP 84, RFC 3704, March 2004.

AFAIK ok.

>               Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.

AFAIK ok.

>               Multihoming Solutions", RFC 4218, October 2005.

AFAIK ok.

- kurtis -

---

From: [email-masked]
Date: Tue, 8 Aug 2006 12:55:18 +0000

> Certainly we have learned a thing or two since 1995.

	not overlooking it.  but am not sure that RFC 1881 allows for 
	the delegation to be revolked.  Surely your not impuning that the
	IETF could reclaim IPv6 from the IANA and its subsiquent  delegations
	to RIR's?  Are you?
 
> by IETF discussions. That still seems to be happening, fortunately.

	As I indicated earlier, MOST of the RIRs came AFTER these RFCs
	came into existance.  And as far as I am aware, there is no special
	"RIR" class of participation in the IETF, since IETF activity is 
	by individual.  Certainly the RIR policy process is based on 
	individual participation.  Statements from the IETF about how they
	think address assignment practices should occur are, on occasion,
	are taken by indivduals and crafted into policy proposals. But then
	the proposals are from individuals, not the IETF.

---

From: David Meyer <[email-masked]>
Date: Tue, 8 Aug 2006 07:35:25 -0700

In addition to what Kurtis said below...

> updated rather than moved to historic.

	Yep, and you might substitue the BGP-4 version:

	[RFC4274] Meyer, D. and K. Patel," BGP-4 Protocol
	          Analysis", RFC 4274.

> >              Aggregation Strategy", RFC 1519, September 1993.

	This one will be updated by draft-ietf-grow-rfc1519bis-04
	(which is in the rfc editor's queue).

	--dmm
m

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Aug 2006 16:35:48 +0200

> 	IETF could reclaim IPv6 from the IANA and its subsiquent  delegations

It does say that IANA can revoke allocations if a registry does
something really, really bad - but I agree, any wholesale revocation
would be, let's say, unlikely.

> 	the proposals are from individuals, not the IETF.

Well, they may, or may not, become statements of IETF consensus. But
my point wasn't about formalism - I think we all win if RIR people
are active in IETF discussions, and we all lose if they aren't.

      Brian

---

From: [email-masked]
Date: Tue, 8 Aug 2006 15:17:14 +0000

look guys, you asked for opinions, I gave mine.
 i'm going to agree that we may disagree on certain 
 aspects of history and the relative outcomes of choices
 that are made.  i still believe that RFC 1881 and RFC 1887
 are or should be historic.  You may choose to believe 
 differently.  And given your status, you have the power 
 to enforce your beliefs.  I don't.  'nuff said.

--bill

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Aug 2006 11:02:37 +0100

> reviewers have stated that at least some of the documents should be  

Hi Fred,

Around 3 years ago I compiled a list of approaches being discussed in
the multi6 WG at that time.   Some of these may be useful, if only to
jog memories on past approaches.   

Here's what I had in 2003, not updated.

------------------------------------------
* General info/overviews/requirements
------------------------------------------

- The IPv6MH web site
  http://arneill-py.sacramento.ca.us/ipv6mh/

- The Multi6 IETF WG Charter
  http://www.ietf.org/html.charters/multi6-charter.html

- Requirements for IPv6 Site-Multihoming Architectures
  http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt
  (Expires 30 Oct 2002) (!!!)

- IPv4 Multihoming Motivation, Practices and Limitations
  http://www.watersprings.org/pub/id/draft-ietf-multi6-v4-multihoming-00.txt
  (Expired)

- Survey on proposed IPv6 multi-homing network level mechanisms
  http://www.watersprings.org/pub/id/draft-bagnulo-multi6-survey6-00.txt
  (Expired)

------------------------------------------
* Network/router oriented drafts/solutions
------------------------------------------

- MHAP: Multi Homing Aliasing Protocol
  http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
  A router solution, not a host one, for SOHO to full Enterprise networks.
  Some questions over resilience of RV points to attack.
  (No expiry, non-IETF proposal)

- IPv6 Reverse Routing Header and its application to Mobile Networks
  http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-01.txt
  There is some multihomed mobile network discussion in Appendix B.
  (Expires 11 Apr 2003)

- Extension Header for Site-Multi-homing support
  http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mhexthdr-00.txt
  http://www.it.uc3m.es/marcelo/mhExtHdr.txt
  Uses new extension header to carry alternative route information.
  Problem for router vendors to add new header in hardware.
  (Expires 23 Apr 2003)

- GFN
  Geographical aggregation using BGP(?)
  Reference?

- Scalable support for multi-homed multi-provider connectivity
  http://www.watersprings.org/pub/id/draft-rfced-info-bates-multihoming-01.txt
  Routing based methods for IPv4 or IPv6, but old.
  (Expired)

- A proposal for scalable network-level multihoming
  http://www.watersprings.org/pub/id/draft-ramki-multi6-nlmp-00.txt
  Uses BGP/tunnels.
  (Expired)

- Multi Homing Translation Protocol (MHTP)
  http://www.watersprings.org/pub/id/draft-py-multi6-mhtp-01.txt
  A predecesor to MHAP
  (Expired)

- GSE - An Alternate Addressing Architecture for IPv6 (aka 8+8)
  http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt
  A set of approaches that generally uses rewriting at the border router.
  (Expired)

- GSE+ - An Alternate Addressing Architecture to GSE
  http://www.watersprings.org/pub/id/draft-durand-gse+-00.txt
  (Expired)

- Multihomed routing domain issues for IPv6 aggregatable scheme
  http://www.watersprings.org/pub/id/draft-ietf-ngtrans-6bone-multi-01.txt
  Would probably need AH protection.
  (Expired)  

- IPv6 Multihoming with Route Aggregation
  http://www.watersprings.org/pub/id/draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt
  (Expired)

- Routing support for IPv6 Multi-homing
  http://www.watersprings.org/pub/id/draft-bragg-ipv6-multihoming-00.txt
  Uses loose source based routing.
  (Expired)

------------------------------------------
* PI addressing based drafts/solutions
------------------------------------------

- An IPv6 Provider-Independent Global Unicast Address Format
  http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt
  Application and Use of the IPv6 Provider Independent Global Unicast 
  Address Format
  ttp://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt
  Use WGS-84 positioning for geographic PI address allocation.
  (Expires Mar 2003)

- Provider-Internal Aggregation based on Geography to Support Multihoming 
  in IPv6
  http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt
  Suggests geograophically based aggregation of provider address space.
  (Expires Apr 2003)

- GAPI: A Geographically Aggregatable Provider Independent Address Space 
  to Support Multihoming in IPv6
  http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt
  An address allocation scheme based on geography and city size.
  (Expires Apr 2003)

------------------------------------------
* Host-oriented drafts/solutions
------------------------------------------

- Host-Centric IPv6 Multihoming
  http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-01.txt
  (Expires 24 Dec 2002)
  Proposing a host multihoming solution using largely existing components.
  http://arneill-py.sacramento.ca.us/ipv6mh/HostCentricMulti6.pdf
  (IETF55 slides)

- Default Address Selection for IPv6 
  http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-09.txt  (Expires 6 Feb 2003)

- SCTP
  RFC2960 (Stream Control Transmission Protocol)
  Also: RFC3257 (applicability), RFC3286 (introduction), RFC3309.
  A protocol using heartbeats to detect path availability for multihoming.
  http://arneill-py.sacramento.ca.us/ipv6mh/ipv6mh-sctp.pdf
  (IETF55 slides)

- The Architecture of End to End Multihoming
  http://www.ietf.org/internet-drafts/draft-ohta-e2e-multihoming-03.txt
  An end to end (host-based) proposal
  (Expires Apr 2003)

- Multihoming issues in the Stream Control Transmission Protocol
  http://www.watersprings.org/pub/id/draft-coene-sctp-multihome-03.txt
  (Expired)

- Multi-homed Host Support in IPv6
  http://www.watersprings.org/pub/id/draft-shand-ipv6-multi-homing-01.txt
  Host-based, includes requirements
  (Expired)

- Multi-homed TCP
  http://www.watersprings.org/pub/id/draft-huitema-multi-homed-0.txt
  The first multihoming draft?  
  (Expired)

------------------------------------------
* Two-space drafts/solutions
------------------------------------------

- HIP: The Host Identity Payload
  http://www.watersprings.org/pub/id/draft-moskowitz-hip-05.txt
  http://www.watersprings.org/pub/id/draft-moskowitz-hip-arch-02.txt 
  http://homebase.htt-consult.com/~hip/