In message <17350.1318379...@marajade.sandelman.ca>
Michael Richardson writes:
>

We may all be in violent agreement.
 
>  
> >>>>> "Erik" =3D=3D Erik Nordmark <nordm...@cisco.com> writes:
>     >> 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!
>  
>     Erik> It sure would be good to try to find some data on this.
>  
> But, for many many years, ISPs did not support having a sharing device.
>  
> Not that they do, ISP insist that the box be *their* box, and as that
> box is sometimes broken, limited, etc. the customer has to provide their
> own.  Again, if the ISP is called, it's "not their problem".


The ISP often has a dumb box that gets a DHCP allocation when turned
on and then does NAT.  For small business service, it may also get a
fixed single IPv4 address, or less often a block and have the ability
to accept an ARP from the customer side in that range (no DHCP).  By
default it does NAT and DHCP for everything else.

If the ISP is an MSO and doing VOIP, their staff usually plugs it in.
Otherwise if left to the customer, they would get the call.

If it Vonage or similar VOIP provider, then they get the call.


>     Erik> While I can see that we can build the internals of the home
>     Erik> network with devices without a designated uplink
>     Erik> (automatically configure prefixes, the routing protocol etc),
>     Erik> what I don't understand is how the connectivity to the ISP
>     Erik> would happen.
>  
>     Erik> How do you see that working?  Will each router try the
>     Erik> protocols it would use against the ISP (PPPOE, DHCP PD, etc)
>     Erik> on every port? Or on every port where it doesn't find a OSPF
>     Erik> (or whatever home routing protocol we choose) neighbor? Or
>     Erik> does the user have to configure the Customer Edge Router to
>     Erik> say "port eth0 is the WAN port?"
>  
> Basically what you suggest.
> For Cable and any access link that uses DHCP and Ethernet directly, the
> fact that you get a DHCP with a PD is a clue that this is the WAN link.
> For DSL using PPPoE (those who pay a bit more can have DSL without
> PPPoE), then a username/password is required, and yes, the user has to
> configure this.

This is generally the case.  A router should not start handing out PD
or even IPv4 NAT space until it gets and address from elsewhere.  If
it gets a real address (not a PI), then that should be preferred over
some device that handed out a NAT address with a default route to
itself even though it had no uplink.

Case in point: DHCP is not a routing protocol.  You have one shot to
hand over a default route.  If its wrong it can be bandaided with ICMP
redirects for hosts that don't have a zero config routing protocol
running.  But that is the best that can be done with the NAT and DHCP
kludge that is in place today.

We can whine about it or we can define something better with
sufficient backwards compatibility.

> However. in many cases, this is pre-configured by the ISP, as the
> "router" and DSL modem is combined into a single box.  Often this also
> means that you can't plug it in wrong, as the uplink is an RJ11 rather
> than RJ45.

This is true only where where "it" is a VOIP product giving you an
RJ11 and it is integrated into the same box as the DOCSIS or DSL modem
and home router.

>     Erik> I don't think arbitrarily stupid way can possibly work, since
>     Erik> that doesn't ensure that the home network is internally
>     Erik> connected. If the user connects three routers in the den
>     Erik> together, but those are not connect to the rest of the house,
>     Erik> then no protocol we come up with can fix that.
>  
> a) That's okay, because the three routers in the Den plugged in that way
>    won't affect the router in the basement which is doing fine.
>  
> b) Actually, the three routers in the Den might see the wifi from the
>    basement, and might join it.

That would be nice.  I think Erik's point is that the audio system
should still get a DHCP address and a (bogus) default route so that it
can talk to the wireless speakers in the room which also get
addresses.

Michaels point about going through the WiFi is interesting in that in
the current model this wouldn't work.  An access point doesn't talk to
another access point over the radio by default.  They usually pick
different channels specifically to avoid each other.  If the access
point was integral to or hanging off the routers by a Ethernet, in the
uplink model, it wouldn't help even if they did talk to each other.

>     Erik> Supporting arbitrary topology (as opposed to just trees) is
>     Erik> good in that it enables redundant internal topologies. But
>     Erik> getting to a redundant topology requires a deeper knowledge by
>     Erik> the users than mandating a tree. More rope. Doesn't mean it is
>     Erik> simpler for the users.
>  
> It's not enough to support only a tree.  It is way too easy to wind up
> with loops without really intending it.  My laptop has four interfaces: wired,
> wireless, USB ethernet (to mobile phone), and internal bridge to a VM.
> Similarily, my phone has three interfaces: USB ethernet, wifi, and 3G.

Yep.  Good example.

> So my laptop and phone can instantly create two links: wifi and USB.
> My phone + AP + laptop can also have a loop via wifi + wired.=20=20
> I don't need all these links up, but I really do want these devices
> smart enough to just bring up connectivity whenever they can.

There just needs to be a preference.  A zero config routing protocol
can deal with your laptop going out of WiFi range or the Ethernet wire
getting pulled when you leave a desk and fall back to the phone USB
Ethernet, with the phone doing the same.

The NAT situation has made quite a mess of this.  NAT plus a default
route through a routing protocol would be a big step forward.  A
routing protocol can change the default route and cost quickly as
opposed to DHCP which can't change the default and has no concept of
changing a route preference.

All of this has to be zero config such that the consumer just plugs it
in and it all works.  Otherwise it just makes a support nightmare.

Curtis
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to