Subject: RE: Why?

From: "Michel Py" <[email-masked]>
Date: Sat, 12 Mar 2005 12:29:26 -0800

> Noel Chiappa wrote:
> The problem with this is that multiple addresses were adopted
> as the way to do large-scale multi-homing (i.e. having a lot
> of multi-homed sites) because it was the only approach that
> seemed technically feasible within the existing architecture
> (both routing, and the various namespaces).

Indeed.

> It may well be true that in practise, having several addresses
> (in the sense of "names that identify both location and
> identity") is unworkable. If so, that inevitably means that
> scalable multi-homing is not practical with IPv6.

I came to the same conclusion myself a while ago.

We all came up with IPv6 scalable multi-homing solutions that were more
or less complex and more or less workable. Some of us acknowledged that
there was no single solution, and all of us acknowledged early in the
game that the solution we proposed would not be as simple as IPv4
multi-homing.

I realize now that this is where we erred: by shifting the multi-homing
problem from the ISP to the end-user, we made a less-palatable protocol
that is adoption-challenged.

We forgot to KISS. Mea culpa.

Michel.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Kevin Loch <[email-masked]>
Date: Sat, 12 Mar 2005 16:24:54 -0500

> that is adoption-challenged.

Then shift it back to the ISP's [1]:

- Encourage RIR's to allocate /32's to large multihomed end sites 
(connected to 3 or more upstreams)
- Use something like alternate path encoded addresses/routing for 
trivial multihoming (2 upstreams)

Allocating anything longer than /32 is asking for a massive swamp.
It's bad enough that ARIN is issuing /48 microallocations as many 
operators are only filtering routes longer than /48 right now.
Alternate path routing allows you to set the bar a bit higher for 
getting PI space and allows anyone with two connections to multihome 
(including people who couldn't multihome in IPv4).

Kevin Loch

[1]http://www.ietf.org/internet-drafts/draft-loch-multi6-alternate-path-encoding-03.txt

    "While many IPv6 multihoming methods require changes to host
    software, this method only requires changes to routers.  This will
    make widespread implementation far more practical and likely in the
    near term than methods that require upgrading host software (provided
    that router vendors support this feature)."

---

From: Bill Manning <[email-masked]>
Date: Sat, 12 Mar 2005 13:39:14 -0800

> I came to the same conclusion myself a while ago.

	may i recommend reading/reviewing the NIMROD
	architecture?

> Michel.

--bill

---

From: shogunx <[email-masked]>
Date: Sat, 12 Mar 2005 16:23:15 -0500 (EST)

> (including people who couldn't multihome in IPv4).

You mean like this?

eth0      Link encap:Ethernet  HWaddr 00:00:39:CC:09:D8
          inet addr:192.168.23.23  Bcast:192.168.23.255  Mask:255.255.255.0
          inet6 addr: 2001:618:400:7702:200:39ff:fecc:9d8/64 Scope:Global
          inet6 addr: fe80::200:39ff:fecc:9d8/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:607020 errors:0 dropped:0 overruns:0 frame:0
          TX packets:406935 errors:0 dropped:0 overruns:0 carrier:0
          collisions:280056 txqueuelen:100
          RX bytes:797508016 (760.5 MiB)  TX bytes:144860030 (138.1 MiB)
          Interrupt:11 Base address:0xf00

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

wlan1     Link encap:Ethernet  HWaddr 00:05:5D:5B:ED:01
          inet addr:192.168.100.3  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: 3ffe:bc0:ce9:1:205:5dff:fe5b:ed01/64 Scope:Global
          inet6 addr: fe80::205:5dff:fe5b:ed01/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:438862 errors:0 dropped:88 overruns:0 frame:0
          TX packets:437976 errors:38 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:222239226 (211.9 MiB)  TX bytes:234742263 (223.8 MiB)
          Interrupt:3 Base address:0x180

Scott

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/