On 10/10/11 5:33 PM, Curtis Villamizar wrote:
In message<[email protected]>
Erik Nordmark writes:
On 10/8/11 6:13 AM, Jari Arkko wrote:
I like this, with the possible exception of using ULAs and your desire
to deprecate prefixes as soon as connectivity goes down. (Speaking as
someone whose prefixes got invalidated two months ago but who hasn't
been home long enough to fix the problem, but my devices still happily
communicate with each other using the old prefixes :-) I also agree with
Erik that loop and arbitrary topologies is not really required. But the
people in the interim at least seemed to say yesterday that we want to
go there.
I think there are different scopes being discussed.
The one I put forth is how to enable existing IPv4 NATting consumer home
routers (which all have a designated uplink port, and support multiple
home routers by nested NATting) have a way to support IPv6 without
requiring any IPv6 NATs. That doesn't seem to be a difficult problem
(which perhaps makes it uninteresting for some of us), but to me it
seems like an important short-term problem to solve.
The larger scope is around arbitrary topologies, no designated uplink
port, and perhaps also multihoming. Plenty of problems to solve around
autoconfiguring routing protocols, stable prefix assignment to links,
multihoming, etc.
Erik,
I really don't know how many support calls are just the consumer
plugging the computer into the wrong Ethernet port on the NAT box and
the uplink on the other port and then not being able to figure out
what is wrong. All the cables fit in the connector. It should work!
It sure would be good to try to find some data on this.
If all the ports are the same, no designated uplink, that is better.
While I can see that we can build the internals of the home network with
devices without a designated uplink (automatically configure prefixes,
the routing protocol etc), what I don't understand is how the
connectivity to the ISP would happen.
How do you see that working?
Will each router try the protocols it would use against the ISP (PPPOE,
DHCP PD, etc) on every port? Or on every port where it doesn't find a
OSPF (or whatever home routing protocol we choose) neighbor? Or does the
user have to configure the Customer Edge Router to say "port eth0 is the
WAN port?"
FWIW I haven't seen any discussion to try to automate this. The manual
configuration would be just as error prone as making the distinction
between the yellow WAN port and the blue LAN ports on current home gear.
If you get an IP address via DHCP on one and none of the others, it
may be the uplink and try doing NAT. What may be needed is a IPv4
equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router
that knows how to respond to it. The other routers ask for a IA_PD
and the provider modem/router responds with part of 10/8 on each
interface (and does NAT).
Presumably DHCP could be used within the home for address (and
potentially prefix) configuration, thus I don't think we can assume that
just because some neighbor on some port responds to a DHCP packet that
it is the WAN port. For all we know, the neighbor might be a DHCP relay
for the home network.
The idea is that the consumer can plug things in in arbitrarily stupid
way and it will all still work well enough to not require a support
call. It might work better if set up right, but good enough if set up
wrong. Perhaps GbE can be preferred over 100baseT over 10baseT and
somewhere between 100baseT over 10baseT or after 10baseT fits WiFi.
Beyond that metrics for multiple WiFi hops can be channel aware.
I don't think arbitrarily stupid way can possibly work, since that
doesn't ensure that the home network is internally connected. If the
user connects three routers in the den together, but those are not
connect to the rest of the house, then no protocol we come up with can
fix that.
If the user wants to have sufficient redundancy (e.g., so that their
teenagers can power off all the gear in the game room with breaking the
Internet connectivity for half of the devices in the home, then clearly
there is a need to understand the topology (wired or wireless) to know
where there are potential single points of failure.
Supporting arbitrary topology (as opposed to just trees) is good in that
it enables redundant internal topologies. But getting to a redundant
topology requires a deeper knowledge by the users than mandating a tree.
More rope. Doesn't mean it is simpler for the users.
Erik
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
