Subject: RE: BGP style solutions

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 18:29:03 -0800

> Peter Tattam wrote:
> What are the current BGP/routing style solutions that
> are on the table to solve the MH problem?

Have a look at MHAP, it's based on BGP. Don't waste too much time trying
to figure out the draft, just ask questions.

http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt

Michel.

---

From: Tim Chown <[email-masked]>
Date: Fri, 22 Nov 2002 02:51:42 +0000

Hi,

Peter's question regarding BGP methods reminded me...

As part of the series of IPv6 multihoming meetings here this week in
Atlanta (thanks Michel and Iljitsch!), I have noted the current
and past drafts and tried to categorise them into the solutions 
spaces mentioned:

- host-based
- router based
- aggregatable pi space methods
- two-space methods

I'm reviewing these (and note an existing 12-18 month old review), but 
feel free to comment on those listed.  Note very few are active.  I'll
also post soon some summary of the discussions we've had (which focus
on a small number of the methods below, of course).

Tim

------------------------------------------
* 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/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sat, 23 Nov 2002 17:20:42 +0100

Hi again,

Just a precision about your comment

>   Problem for router vendors to add new header in hardware.

There is no need that the proposed extension header is supported in ALL
routers.
Since the Extension header is only processed when the destiantion address is
unreachable, some special upgraded routers can inject a sink route in order
to attact all traffic addressed to unreachable destiantions, so only a few
routers must support the new extension header.

Another comment is that i am not so sure that this proposal can be viewed as
a network/router oriented proposal, since some host support is needed. In
fact, the solution requires some sort of cooperation between hosts and some
routers.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sat, 23 Nov 2002 17:20:40 +0100

Hi Tim,

I include some additional documents/pointer to your list that may be of

>   Geographical aggregation using  BGP(?)

I guess would be
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00
.txt

There was a Metro addressing proposal by Deering but I haven?t been able to
find the ID

Tattam?s proposal of preserving established TCP connections.

There is LIN6 original proposal draft-teraoka-ipng-lin6-01.txt
And the new modified proposal by Otha at
http://www.lab1.kuis.kyoto-u.ac.jp/~arifumi/paper/saint2003html/

* IPv4 solutions

RFC 2260
draft-ietf-idr-symm-multi-prov-02.txt (very expired)

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 23 Nov 2002 17:29:43 +0100 (CET)

> There was a Metro addressing proposal by Deering but I haven?t been able to

I asked him about this a while ago and he said there isn't really much
on paper in this area. There are some slides somewhere, that's pretty
much it. I can dig them up if you can't find them.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 23 Nov 2002 17:35:19 +0100 (CET)

> There is no need that the proposed extension header is supported in ALL

Essentially, the hardware guys say they need to specifically support a
header in hardware to be able to forward packets having this header in
it in the fast path. See the message I just posted to ipv6mh:

http://arneill-py.sacramento.ca.us/public/ipv6mh/ or
http://arneill-py.sacramento.ca.us/public/ipv6mh/Re:%20(ipv6mh)%20the%20Rebel%20Alliance%20meetings%20in%20Atlanta%20(long).EML?Cmd=open

Iljitsch

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Nov 2002 19:04:09 +0200 (EET)

> it in the fast path. See the message I just posted to ipv6mh:

That seems to crap, or I misunderstood something very badly.

There's _nothing_ special about extension headers when forwarding is 
considered.

Hop-by-Hop option + router Alert is another issue.

Also, when you're the destination address (like w/ Routing Header) and
want to process the header in hardware, support has to be in of course.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sat, 23 Nov 2002 18:36:11 +0100

Hi Iljitsch,

> on paper in this area. 

Ok, thanks

> There are some slides somewhere, that's pretty

I guess that they are the ones posted in the ipv6mh page.

Regards, m

---

From: Ole Troan <[email-masked]>
Date: Sun, 24 Nov 2002 00:48:03 +0000

Iljitsch,

> it in the fast path. See the message I just posted to ipv6mh:

that is not strictly true. for forwarding a packet there is no need to
look at the extension header chain, apart from the hop-by-hop option
case (hop by hop is typically done in software so don't expect much
performance). for packet filtering the extension headers will have to
be supported if parsing the subsequent headers are required. unknown
extension headers should be expected by all implementations, not too
dissimilar to an encrypted packet.

so a solution which:
 - don't use hop-by-hop
 - don't use routing headers
 - don't require insertion of extension headers

should be all right to process for routers.

I have only browsed the abovementioned draft. if it is expected that a
typical case is that no route for the destination exists and that the
alternative prefix option is there, that would require hardware
changes. e.g an implementation today could send the ICMP error message
from software, and the hardware could rate-limit the punting of these
packets, so software wouldn't even see them all.

/ot

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 24 Nov 2002 16:43:46 +0100

Hi Ole,

> changes.

It is expected that the header is there but it is not expected that the
header need to be processed fequently. I mean, extension header processing
will only be needed when an outage occurs, which it is not expected to be
very frequent.

I think that it would not be too much problem that packets that need to have
the newly defined extension header processed are coursed through the slow
path, since these are not expected to be the common case, only when a path
outage occurs.

My main concern is how packets that carry the newly defined extension header
but do not need header processing are processed by the routers, slow path or
fast path?

Thanks, marcelo

> e.g an implementation today could send the ICMP error message