Subject: [homenet] Homenet strawman slides

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Oct 2011 14:11:09 -0400

All,

here are my slides from the unscheduled talk at the interim meeting.

Comments appreciated, and if anyone were so inclined, help writing it up
would also be much appreciated.

Cheers,
Lorenzo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 11:25:33 -0700

> would also be much appreciated.

Lorenzo,

The slides say:
"Support arbitrary topologies including loops"

What is the implication of that on IPv4?
Are you assuming that the dual-stack home network will delegate IPv4 
prefixes and route IPv4, with no internal NATs?

How would someone transition to such an IPv4 network from their current 
daisy-chain or tree of IPv4 NATs?

The other question is about the assumptions about the requirements of 
stability of the prefixes that are assigned to links.

For routing you have:
  - Survive loss of any router for any time period
  - Works regardless of router boot order

That combined with your strawman prefix assignment seems to result in 
the set of prefixes assigned to a link changing each time a router goes 
down. Am I reading things correctly?

FWIW such an unstable prefix assignment doesn't sound useful. Assuming 
we allow routers to come and go, I think we want the hosts assigned to a 
link see the same prefixes for that link over time.

    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Oct 2011 14:39:28 -0400

> daisy-chain or tree of IPv4 NATs?

IPv4 won't work. You would likely never get to such a topology (or never
stay there) if you need IPv4, since you would notice it's not working and
unplug it. :-) However, it would be nice if IPv6 were able to work in this
situation as well, so if you don't need IPv6, you can plug things in any
random way and have things work.

Supporting arbitrary topologies and loops is not an absolute requirement
(especially loops, since loops will break IPv4), but it would be nice to
work in multiple topologies, and you have a routing protocol anyway then
being able to support loops comes for free.

> That combined with your strawman prefix assignment seems to result in the
> set of prefixes assigned to a link changing each time a router goes down. Am
> I reading things correctly?
>

To achieve stability, routers would need to write the prefixes they form
into stable storage (like they would a DHCP lease). I think it's reasonable
to write to stable storage whenever you configure a new prefix or change an
existing prefix (but not if you simply refresh it). If the router comes back
up and nobody has the prefix, it would simply claim it back. If someone else
has it, it would have to just form a new one using loop detection.

Cheers,
Lorenzo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 13:18:19 -0700

On 10/7/11 11:39 AM, Lorenzo Colitti wrote:
> On Fri, Oct 7, 2011 at 14:25, Erik Nordmark <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The slides say:
>     How would someone transition to such an IPv4 network from their
>     current daisy-chain or tree of IPv4 NATs?
>
>
> stay there) if you need IPv4, since you would notice it's not working
> and unplug it. :-) However, it would be nice if IPv6 were able to work
> in this situation as well, so if you don't need IPv6, you can plug
> things in any random way and have things work.
>

Unfortunately I missed Fred's discussion yesterday (hopefully there will 
be a recording) but the above seems backwards.

Today there are IPv4 NATting RGs, and there are cases when you end up 
with multiple (could be tied to separate services or other 
functionality) in a home.
Seems like we'd like to be able to introduce IPv6 support without NATs 
into such a home network without breaking IPv4.

You seem to focus on a clean slate approach.

> into stable storage (like they would a DHCP lease).

That can be used to get a stable prefix per interface on the router, 
which I observe isn't the same as getting one (or a set of) stable 
prefixes assigned to the link to which that interface is attached.

> I think it's
> reasonable to write to stable storage whenever you configure a new
> prefix or change an existing prefix (but not if you simply refresh it).
> If the router comes back up and nobody has the prefix, it would simply
> claim it back. If someone else has it, it would have to just form a new
> one using loop detection.

In your view, if there is a single prefix assigned to the home by the 
ISP, and there are three routers connected to a particular link in the 
home, would each of those three routers assign a different prefix to the 
link?

Am I missing something?

    Erik

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Oct 2011 17:18:28 -0400

> In your view, if there is a single prefix assigned to the home by the ISP, and there are three routers connected to a particular link in the home, would each of those three routers assign a different prefix to the link?
> 
> Am I missing something?

see the zospf draft. the DR of the link will assign the prefix for the link. the BDR should also store that chosen prefix into stable storage. of course if you power off both the DR and the BDR and power up a new 3rd router, the link will get a new prefix.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Oct 2011 17:41:35 -0400

On Fri, Oct 7, 2011 at 16:18, Erik Nordmark <[email-masked]> wrote:

> Today there are IPv4 NATting RGs, and there are cases when you end up with
>> multiple (could be tied to separate services or other functionality) in a
>> home.
>>
> Seems like we'd like to be able to introduce IPv6 support without NATs into
> such a home network without breaking IPv4.
>

This approach doesn't break IPv4, but it will work regardless of whether
IPv4 is working or not. So if/when IPv4 goes away you can plug any port into
any other port, even in topologies that IPv4+NAT can't handle, and it will
still work.

I don't think "doesn't work if IPv4 doesn't work" should be a goal.

> You seem to focus on a clean slate approach.

More than clean slate it's ships in the night.

In your view, if there is a single prefix assigned to the home by the ISP,
> and there are three routers connected to a particular link in the home,
> would each of those three routers assign a different prefix to the link?

No, the intention is that there be only one prefix on the link.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 15:08:51 -0700

> see the zospf draft. the DR of the link will assign the prefix for the link. the BDR should also store that chosen prefix into stable storage. of course if you power off both the DR and the BDR and…

The zospf draft (see section 3.6) declares a conflict if two routers 
attached to the same link pick the same IP subnet prefix for that link. 
That doesn't seem what we want.

And zospf doesn't talk about using stable storage; doesn't seem to have 
any notion of providing stable prefixes assigned to the links.

Thus this problem remains to be solved AFAICT.

I think we first need to agree on what we think are the requirements on 
prefix stability. What if one of the routers attached to the link fails 
and is replaced by a different router?
What if a link partitions? And later merges?
What the user intentionally splits (partitions) a link (e.g., to create 
a separate link for the teenage game room); should the network 
automatically pick a new prefix for that new link? (How does that 
interact with the prefix being in stable storage on the router.)

One thing to keep in mind as we think about these requirements is that 
if the user has created a bridged Ethernet with no routers, all of the 
above will work naturally; might take seconds to relearn when the 
topology changes but there is no manual intervention needed.
Is that the goal for this prefix assignment?

Who is working on the requirements document? ;-)

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 07 Oct 2011 15:21:29 -0700

On 10/7/11 2:41 PM, Lorenzo Colitti wrote:

>     Seems like we'd like to be able to introduce IPv6 support without
>     NATs into such a home network without breaking IPv4.
>
>
> IPv4 is working or not. So if/when IPv4 goes away you can plug any port
> into any other port, even in topologies that IPv4+NAT can't handle, and
> it will still work.
>

So if we take a topology below (if it doesn't display correctly, look at 
figure 7 in 
http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-00)

                    +------+--------+                    \
                    |     IPv6      |                     \
                    | Customer Edge |                      \
                    |    Router 1   |                      |
                    +------+--------+      +------------+  |
        Network A          |               |            |  |
      +-------------+------+-------+-------+-----+      |  |
      |             |      |       |             |      |  |
+----+-----+ +-----+----+ |  +----+-----+ +-----+----+ |  |
|IPv6 Host | |IPv6 Host | |  |   IPv6   | |IPv6 Host | |  |
|          | |          | |  |  Router 2| |          | |  |
+----------+ +----------+ |  +----+-----+ +----------+ |  |
                           |       |                    |  |
                           |       +-------------+      |  |
                           |       | Network B   |      |  |
                           |       |             |      |  |
                           |  +----+-----+ +-----+----+ |  |
                           |  |   IPv6   | |IPv6 Host | |  |
                           |  |  Router 3| |          | |  |
                           |  +----+-----+ +----------+ |  |
                           |       |                    |  |
                           |       +--------------------+  |
                           |         Network C/A           |
                    +------+--------+                      | End-User
                    |     IPv6      |                      | networks
                    |    Router 4   |                      |
                    +------+--------+                      |
        Network D          |                               |
      +-------------+------+--------+---------+            |
      |             |               |         |            |
+----+-----+ +-----+----+     +----+-----+ +-+------+-+   |
|IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |   |
|          | |          |     |          | |          |   /
+----------+ +----------+     +----------+ +----------+  /

If this was an IPv4/NAT network it wouldn't reliably work, since there 
is a NAT loop involving R3 and R2. Thus in IPv4 the link out of the 
bottom of R3 would actually not exist.

I think what you are saying is that it is fine if the deployment of IPv6 
encourages folks to create the R3/R2 loop above, even if that makes IPv4 
fail.

I find such an approach rather unrealistic; it might be reasonable in 
greenfield IPv6-only home networks but I would never recommend that as a 
way to move current IPv4 home networks forward.

I thought we wanted the solution to apply to the average Joe, and not 
just experts like ourselves.

Regards,
     Erik

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Oct 2011 18:36:05 -0400

On Oct 7, 2011, at 6:08 PM, Erik Nordmark wrote:

> The zospf draft (see section 3.6) declares a conflict if two routers attached to the same link pick the same IP subnet prefix for that link. That doesn't seem what we want.
> 
> And zospf doesn't talk about using stable storage; doesn't seem to have any notion of providing stable prefixes assigned to the links.
> 

> 
> I think we first need to agree on what we think are the requirements on prefix stability. What if one of the routers attached to the link fails and is replaced by a different router?
> What the user intentionally splits (partitions) a link (e.g., to create a separate link for the teenage game room); should the network automatically pick a new prefix for that new link? (How does that interact with the prefix being in stable storage on the router.)
> 
> One thing to keep in mind as we think about these requirements is that if the user has created a bridged Ethernet with no routers, all of the above will work naturally; might take seconds to relearn when the topology changes but there is no manual intervention needed.

No manual intervention is definitely a goal.

> Who is working on the requirements document? ;-)

For now, the arch document will be capturing as close as we are getting to formal requirements in an ID.... mostly principles and high-level requirements. 

I'm not convinced a detailed or separate requirements document for any of our 5 areas could be produced without it becoming a reverse engineering exercise from various solutions anyway. We tried to have a formal "just the requirements" discussion during the meeting, and what I heard was quite a bit of solution discussion couched in requirements language anyway.

- Mark

> 
>   Erik
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Mark Townsley <[email-masked]>
Date: Fri, 7 Oct 2011 18:38:40 -0400

On Oct 7, 2011, at 6:21 PM, Erik Nordmark wrote:

> 
> 
> I thought we wanted the solution to apply to the average Joe, and not just experts like ourselves.

That's the point though. Experts know how to construct a network without loops (presumably), Joe doesn't. You're pushing the problem from the protocols to the documentation.

- Mark

---

From: Acee Lindem <[email-masked]>
Date: Sat, 8 Oct 2011 06:35:52 -0400

Hi Erik, 
My opinion is that OSPF auto-configuration is a separate draft from using OSPF for prefix assignment within the routing domain. The zOSPF draft would not be used as is - the work from 2002 would be acknowledged but we'd start with a clean slate. 
In answer to your other question, I don't there are any implementations of OSPF or ISIS that support auto-configuration today since there has, heretofore, not been a strong requirement. 
Thanks,
Acee
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Erik Nordmark [[email-masked]]
Sent: Friday, October 07, 2011 6:08 PM
To: Ole Troan
Cc: [email-masked]; Lorenzo Colitti
Subject: Re: [homenet] Homenet strawman slides

    Erik

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Oct 2011 09:13:01 -0400

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 am interested in trying to write up a solution.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Oct 2011 09:14:58 -0400

Erik,

> Thus this problem remains to be solved AFAICT.

The draft is useful background, but I think some work remains. Maybe even a lot of work. So yes.

> What the user intentionally splits (partitions) a link (e.g., to create a separate link for the teenage game room); should the network automatically pick a new prefix for that new link? (How does t…

We talked about the stability requirements on Thursday a bit. From my perspective the requirement is that crashes, power outages/recycles, and addition of new devices must not cause existing allocations to change. Other changes.... they may, and I think it would be too much effort and complexity to try to prevent all changes in all situations.

> Who is working on the requirements document? ;-)

Ole was working on the slides for the requirements, but many of the entries probably need some further details. (Like Mark, I think it would be probably more worthwhile to move a bit back and forth between solutions and requirements rather than make a pure requirements list.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Oct 2011 09:15:11 -0400

Erik,

> In your view, if there is a single prefix assigned to the home by the ISP, and there are three routers connected to a particular link in the home, would each of those three routers assign a differe…

I think we need efficient prefix assignment (no double or triple assignments) and stability. I think this still needs some work, but should be doable.

Jari

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 12:34:39 -0400

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:
    >> I think it's reasonable to write to stable storage whenever you
    >> configure a new prefix or change an existing prefix (but not if
    >> you simply refresh it).  If the router comes back up and nobody
    >> has the prefix, it would simply claim it back. If someone else

    Erik> In your view, if there is a single prefix assigned to the home
    Erik> by the ISP, and there are three routers connected to a
    Erik> particular link in the home, would each of those three routers
    Erik> assign a different prefix to the link?

    Erik> Am I missing something?

If you had three routers concurrently, then using OSPF terminology, then
only one router would become the Designated Router, and it would
announce the prefix.  The others would have to agree to remember that
prefix for that link. 

If, however, you decided to try three routers in a sequential way
(trying each one out to see if you liked it...), then would get three
prefixes assigned to that link, and remembered by each router.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 12:44:09 -0400

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:
    Erik> I think what you are saying is that it is fine if the
    Erik> deployment of IPv6 encourages folks to create the R3/R2 loop
    Erik> above, even if that makes IPv4 fail.

I think that the word "encourages" is wrong.  "Permits" is the keyword.
Joe can easily create a network today that does not work.  

Just plug his DSL model into a LAN port on the "router", or confuse his
8-port switch with his 8-port home router.

What we are saying is that, the IPv6 portion of the network SHOULD
continue to work, even if the topology can never work for IPv4.

We had a brief discussion (making it out-of-scope very quickly) about
whether or not the loop detection that IPv6 would provide could be
communicated (by a vendor, inside their box) to their IPv4 side, which
would permit them to turn off the R3/R2 loop for IPv4, making things
work.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Oct 2011 11:12:31 -0700

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.

Some things are common across the two; security (determining the 
boundary of the home), DNS, and service discovery.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Oct 2011 11:20:06 -0700

On 10/8/11 6:14 AM, Jari Arkko wrote:

>> I think we first need to agree on what we think are the requirements
>> on prefix stability. What if one of the routers attached to the link
>> fails and is replaced by a different router?
>> What the user intentionally splits (partitions) a link (e.g., to
>> create a separate link for the teenage game room); should the network
> We talked about the stability requirements on Thursday a bit. From my
> perspective the requirement is that crashes, power outages/recycles, and
> addition of new devices must not cause existing allocations to change.
> Other changes.... they may, and I think it would be too much effort and
> complexity to try to prevent all changes in all situations.

I suspect that if we can solve the above cases (e.g., for a link with 
two routers that crash, get powered off and on, and then later the user 
adds a third router to connect up with the garage network), then we will 
end up with something rather complete.

There might be some more difficult aspects if we want to allow a router 
or its interfaces to be repurposed, such as splitting an existing link 
into two separate links. In that case it might be hard to avoid 
renumbering. The requirements question is whether the system needs to be 
able to detect that the link is now (intentionally) partitioned and as a 
result there are two separate prefixes needed for the two separate 
links, or whether the user needs to be able to push the "reset to 
factory defaults" if the user is going to reconfigure the topology in 
such ways.

    Erik

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Oct 2011 16:17:44 -0400

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:
    Erik> There might be some more difficult aspects if we want to allow
    Erik> a router or its interfaces to be repurposed, such as splitting
    Erik> an existing link into two separate links. In that case it
    Erik> might be hard to avoid renumbering. The requirements question

Moving/repurposing a router without a factory reset seems like the
perhaps the most important source of conflict in the architecture that
we discussed.  Particularly if the router is put into a junk drawer for
a few months until it is needed.

So, we might need to consider if we can expire persisted settings after
some long (from the point of view of the network) time, like 1 week...

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 17:33:35 -0700

In message <[email-masked]>

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!

If all the ports are the same, no designated uplink, that is better.
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).

The same loop tolerance can then be built into the IPv4 homenet using
16M addresses provided by NAT as can be provided for the IPv6 subnet
using a globally routable /64 (with its 4B^2 addresses).

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.

> boundary of the home), DNS, and service discovery.

The security boundary of WiFi for non-open WiFi is separate issue.
That can't easily be zero config.  Perhaps two devices can "bond" (in
the "fall in love" analogy sense) over an Ethernet or USB connection
as one way around the configuring WPA issue.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 18:52:07 -0700

In message <[email-masked]>
 
> some long (from the point of view of the network) time, like 1 week...

If it is zero config and its persistent store is DHCP leases, then
they will expire.  OSPF advertisements would have aged out long ago.
It might be worth redoing the router-id selection if it is well past
the maxage limit and there are no adjacencies.

If the router is just power cycled when moving, it should ask for
certain IA-PD and may not get them (or make DHCPv4 requests for a
specific address).  The same link local requestors (or MAC on DHCPv4)
would not be on the new LANs and so the old granted leases that had
not expired would also do no harm.

What persistent storage, beside configuration by the user would last
more than a week?  AFAIK just having DHCP leases lasting more than a
week would also require some user configuration.

Curtis

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 09:47:26 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> If it is zero config and its persistent store is DHCP leases, then
    Curtis> they will expire.  OSPF advertisements would have aged out long ago.
    Curtis> It might be worth redoing the router-id selection if it is well past
    Curtis> the maxage limit and there are no adjacencies.

So, I think you are right in general... the IA-PD might last more than a
week.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 08:23:31 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> I really don't know how many support calls are just the consumer
    Curtis> plugging the computer into the wrong Ethernet port on the NAT box and
    Curtis> the uplink on the other port and then not being able to figure out
    Curtis> what is wrong.  All the cables fit in the connector.  It should work!

So, I was interrupted yesterday, reading homenet email, in order to go
to my neighbour's house and sort out this EXACT problem.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Oct 2011 10:53:34 -0700

On 10/10/11 5:33 PM, Curtis Villamizar wrote:
> In message<[email-masked]>
> Erik Nordmark writes:
>

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.

> 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.

> 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

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Oct 2011 20:03:51 +0200

Erik,

> 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.
> 
> 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.

this is the problem we named "border discovery" during the interim.
there were a few ideas of how that could be done. either implicit or explicit. nothing concluded, and I agree this is an important problem to tackle.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 20:35:56 -0400

>> 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".

    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.  

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.

    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.

    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.

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.  
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.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Oct 2011 09:49:30 +0200

Erik,

btw, "border discovery" needs to be done regardless of topology or prefix assignment solution choice.
on a border you (may) want firewall on, you want a ULA border, you want a organisational or site multicast border...

cheers,
Ole

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 12 Oct 2011 10:07:33 +0200

On 11/10/2011 14:23, Michael Richardson wrote:
> Curtis> plugging the computer into the wrong Ethernet port on the NAT box
> and Curtis> the uplink on the other port and then not being able to figure
> out Curtis> what is wrong.  All the cables fit in the connector.  It should
> work!
> 
> So, I was interrupted yesterday, reading homenet email, in order to go to
> my neighbour's house and sort out this EXACT problem.

My box and the cables at home have connectors in different colors, making
it easy to plug the right cable in the right port.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Oct 2011 09:03:53 -0700

On 10/10/11 1:17 PM, Michael Richardson wrote:
>
>>>>>> "Erik" == Erik Nordmark<[email-masked]>  writes:

FWIW My existing IPv4 NATting home routers don't need to be quaranteened 
for a week; I can just rewire. At worst I have to power cycle.

I thought IPv6 would make things better ;-)

    Erik

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 13:52:22 -0700

In message <[email-masked]>
Michael Richardson writes:

We may all be in violent agreement.
 
>  
> >>>>> "Erik" =3D=3D Erik Nordmark <[email-masked]> writes:
>     >> Erik,
>     >>

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.

> PPPoE), then a username/password is required, and yes, the user has to

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.

> means that you can't plug it in wrong, as the uplink is an RJ11 rather

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.

>    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.

> Similarily, my phone has three interfaces: USB ethernet, wifi, and 3G.

Yep.  Good example.

> My phone + AP + laptop can also have a loop via wifi + wired.=20=20

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 12 Oct 2011 15:23:04 -0700

On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote:
> 
> A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere.

Some routers need to do this, i.e. home routers where service providers charge prohibitive rates for always-on Internet dial-tone and expect subscribers to connect on demand and disconnect after an appropriate idle time.

For IPv4 today, these routers typically use PPPoE on the WAN and they often handle this by assigning RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE to establish the WAN link.

For IPv6, I'm not sure what they should do, but I have some ideas.  Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interface address with RFC 6106 and optionally RFC 3736.  When the DNS query signals PPPoE to establish the WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN accordingly.

I'm not sure this model can be made to work with IPv6, but I wouldn't put it past the telcos to try.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 16:00:15 -0700

In message <[email-masked]>
 
> user have to configure the Customer Edge Router to say "port eth0 is the 

On a DOCSIS or DSL router the provider connection will always (maybe
always) need some configuration, if for no other reason the provider
wants to see an account name and password.

If the provider ships out the DOCSIS or DSL router or installs it,
then they would do that configuration.

Everything *on the homenet side* would be autoconfig and would never
have a need to run certain protocols such as PPPOE.

If the user chooses to set the SSIDs and enable security on WiFi, that
would have to be optional if we wanted true zero config.

> between the yellow WAN port and the blue LAN ports on current home gear.

The goal is to get zero configuration on the homenet side of
homenet/provider demarc.  If the provider supplies equipment, then the
demarc is that equipment with the homenet side of the homenet/provider
link configured ethernets the ethernets and any routers/hosts on the
homenet side zero config.

> it is the WAN port. For all we know, the neighbor might be a DHCP relay 

The reason that a routing protocol is needed is DHCP is quite dumb
about this and DHCP proxy and ARP proxy, and ND proxy provide at most
very limited kludges.

Let us separate DHCP6 from DHCP4 for the moment.  In DHCP4 the
assumption is that the client is always a host (excluding proxy) and
returns a single address.  In DHCP6 link local communication is
possible without an uplink.  With link local and a routing protocol, a
default route can be discoverd if there is one (or more).  Only when
one of the routers on (or adjacent to, depending on demarc style)
acquires a globally routeable prefix (IA_PD or configured, doesn't
matter) can it begin responding to DHCP6 IA-PD requests.  Since IPv6
hosts and routers add aliases (or are supposed to) in the presence of
multiple routeable prefixes returned via IA_PD, if one demarc goes
down, there still should be a route to the rest of the world, even for
the prefix that provider demarc provided.

IPv4 becomes a big kludge because it doesn't have the tools to do this
right.  DHCPv4 and NAT were successful, but to some extent made
mistakes so lets not reuse the parts that didn't work for IPv6.

For IPv4, you'll likely have to give out PI space in the absense of a
clear uplink.  A cycle with no true uplink can end up being a NAT loop
without some changes.  A path vector addition can at least break the
loop (an allocation with no uplink in mind has no path).  If there is
a possible uplink (another router provided a DHCP response), the
subnet of that uplink can go in the path.  If the response came with a
path, the subnet is added.  If your subnet is already in the path,
don't accept it as an uplink.

A big improvement would also be an IPv4 equivalent to IA_PD and a
routing protocol.  At least the loop could end up with a different set
of subnets of net 10 such that routing could work and no NAT.  Then if
a real uplink comes along it will already know what PI subnets are
allocated in the routed portion.  If there are dumb routers that want
to reNAT, then they can't be part of a loop.  Its no worse than now.

> connect to the rest of the house, then no protocol we come up with can 

Link local addresses and a routing protocol works.  Age out the link
local advertisements when allocated a routable prefix.  Routers can
fake proxy ND (just like proxy ARP today) for host that need to think
the link local addresses really are local.

> where there are potential single points of failure.

Its more common than that.  The scope is also supposed to be home and
small home office.

> More rope. Doesn't mean it is simpler for the users.

Supporting arbitrary topology with zero config is not hard for IPv6
but if you start out making it a non-goal for no good reason it won't
be accomplished, at least by this WG.

I do agree though that right now configuring today's two main LS
routing protocols is way too onerous to ever be successful in the
consumer market.  But I think it is a solvable problem.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 20:57:41 -0700

In message <[email-masked]>
james woodyatt writes:
 
> > A router should not start handing out PD or even IPv4 NAT space
> > until it gets and address from elsewhere.

btw - the valid point about serving the site needs was brought up, so
some assignment would be needed in absense of an uplink.

> Some routers need to do this, i.e. home routers where service
> providers charge prohibitive rates for always-on Internet dial-tone
> and expect subscribers to connect on demand and disconnect after an
> appropriate idle time.

For on-demand routing, it makes sense for the router to hand out an
address while not being connected.  I personally haven't seen that
since 56K modems, but OK.  (And I had FR back then).

For the DSL and MSO services I've used, the service was "always up",
unless of course you powered down the CPE.

> For IPv4 today, these routers typically use PPPoE on the WAN and they
> often handle this by assigning RFC 1918 address to the LAN hosts and
> using DNS queries to signal PPPoE to establish the WAN link.

OK.  Client does DNS and that is the "on demand" part.  Fine.  In in
absence of DNS, a ping or TCP SYN would bring it up.

> For IPv6, I'm not sure what they should do, but I have some ideas.
> Basically, the router should advertise as a default router with a
> single ULA prefix and a DNS server at the router's ULA interface
> address with RFC 6106 and optionally RFC 3736.  When the DNS query
> signals PPPoE to establish the WAN link, the DHCPv6 client will ask
> for a IA_PD and update the prefix advertised on the LAN accordingly.
>  

With IPv6 there is no reason that the CPE can't be assigned a
persistant address but bring the connection down.  On power up it
could connect and get it, then bring the link down in the absence of
traffic.  Usually if it is powered up it is because someone want to
use it, so this would be fine.

There is no reason not to hold the IA_PD assignment at the CPE when an
on demand link is down.  That prefix can be requested in the IA_PD
request when there is demand again, just to refresh it and confirm.
The same DNS query can be used as the trigger in on-demand IPv6 as
well.

Curtis

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2011 03:23:17 -0400

>> A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere.

Every IPv4 home router I have ever seen hands out RFC 1918 space regardless of whether an ISP connection is active. This is needed, if nothing else, to manage the router with the classic IPv4 literal in a web browser (yes, this could be done with link-local, but that's not something you can hard-code in documentation or a sticker on the side of the box). 

> For IPv6, I'm not sure what they should do, but I have some ideas.  Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interfac…

"Update" or just advertise the new global prefix alongside the ULA?

- Mark

---

From: Sander Steffann <[email-masked]>
Date: Thu, 13 Oct 2011 10:54:48 +0200

Hi,

> "Update" or just advertise the new global prefix alongside the ULA?

Alongside. The ULA addresses should be stable so that they can always be used internally, independent on the link to the ISP.

- Sander

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 07:46:53 -0400

>> it gets and address from elsewhere.

In other words, your home network should be unusable unless at least one
edge device is connected to the "real world." I can just imagine the
support calls the local provider will get when they have a local outage.

"I'm sorry, sir, but that's the way it works --you can't print or stream
movies from your console unless your internet connection is up."

Yeah, that's going to fly.

:-)

Russ

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2011 11:01:10 -0400

>>>>> "Russ" == Russ White <[email-masked]> writes:

    Russ> In other words, your home network should be unusable unless at
    Russ> least one 
    Russ> edge device is connected to the "real world." I can just imagine the
    Russ> support calls the local provider will get when they have a
    Russ> local outage. 

    Russ> "I'm sorry, sir, but that's the way it works --you can't print
    Russ> or stream 
    Russ> movies from your console unless your internet connection is up."

    Russ> Yeah, that's going to fly.

Please don't mistake idle comments about the history of some devices on
the mailing list for requirements!

I think that we are pretty much in agreement that the home network has
to operate independently of the ISP(s), which is one of the reasons for
ULA, and RFC6204 (Basic Requirements for IPv6 Customer Edge Routers)
already provides for this.  At the 10,000ft level, homenet is "Advanced
Requirements for ..."

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 12:32:43 -0700

In message <[email-masked]>
Mark Townsley writes:
 
> Every IPv4 home router I have ever seen hands out RFC 1918 space
> regardless of whether an ISP connection is active. This is needed, if
> nothing else, to manage the router with the classic IPv4 literal in a
> web browser (yes, this could be done with link-local, but that's not
> something you can hard-code in documentation or a sticker on the side
> of the box).

For IPv4, routes can be installed for non-local link-local addresses
or ULA prefixes can be used if no address is available.

The practice of using 192.168.1.1 should be changed.  The change could
be as simple as a DNS mapping of "local-router." to the link local
addres.  A DHCP host query would get an offer of a DNS server which
would respond with a DNS entry for local-router.  The dot is
significant though if omitted the domain search list would be used
with the last entry presumed blank.  As long as there is no
"local-router." TLD glogally defined this should be OK.  A user with
multiple routers on the subnet can just paste the link-local address
in place.  Maybe routers can look for others and offer a
"local-router-N." for each other router detected.  Then
"http://"local-router." or "http://"local-router-N." can be used if
the user does need to do any config.

There could also be some improvement on the common practice of
allowing a default password on any port except the designated uplink.
In an auto-config router this would never change.  Perhaps this could
be enabled only 10 seconds or so after power up if the factory default
password is in place, at least limiting the exposure.  This could fit
in the manual and maybe even on a sticker.

But yes, IPv4 must hand out a PI address if it has nothing else to
hand out.

> > For IPv4 today, these routers typically use PPPoE on the WAN and
> > they often handle this by assigning RFC 1918 address to the LAN
> > hosts and using DNS queries to signal PPPoE to establish the WAN
> > link.
> > 

I meant "update" in the context of refreshing the IA_PD request at the
provider DHCP server that handed it out the last time the demand
circuit was up.

If the prefix was held while the demand circuit was unused and down,
then no change is needed on the homenet side when the demand circuit
comes back up.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 13:09:13 -0700

> Yeah, that's going to fly.

Maybe mail crossed.  IPv6 can function with just link local and ULA
until it gets a routeable prefix.  IPv4 is stuck handing out a NAT
address if it has no other configuration so modify the second part of
that sentence.

Curtis