Subject: [homenet] automatic prefix management (OSPF or ISIS version)

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 20:31:33 -0500

{possible resend}

Fred,

wrt:  draft-baker-ipv6-isis-automatic-prefix-00

for a network where there is more than one ISP, is it acceptable for a CPE
that has decided that it is PREFIX1:0123::/64 (and gone through the
process of advertising it and backing things off...), to "randomly"
decide to be PREFIX2:0123::/64 when it sees PREFIX2?

I.e. the "0123" is identical for the two prefixes?

This seems a desireable (but not required) property that all the
prefixes on a LAN are similar.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2013 11:38:52 +0900

> I.e. the "0123" is identical for the two prefixes?

In the general case where the prefixes assigned by the operators are of
different lengths, it cannot be. Right?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2013 09:16:21 -0500

>>>>> "Lorenzo" == Lorenzo Colitti <[email-masked]> writes:

    Lorenzo> In the general case where the prefixes assigned by the
    Lorenzo> operators are of different lengths, it cannot be. Right?

True.

If the ISP with the longest prefix is alive first, then the routers 
pick subnet-id parts that fit into that.  If that ISP has provided
enough subnets, then even when another ISP comes along, the "xx23"
part might remain stable for a long time.

I think this is a human friendly feature that none of our protocols
should depend upon, but that nothing should forbid.  Do you agree?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 16:54:10 +0000

> should depend upon, but that nothing should forbid.  Do you agree?

I think we have violent agreement here. The text we're discussing is

      <section anchor="allocation"
               title="Subnet prefix allocation and announcement">
        <t>Each router advertising a <xref target="RFC5308">Reachability TLV
        </xref>, including a pseudonode on a LAN, when it receives the
        Autoconfiguration TLV Advertisement, calculates and announces a more
        specific prefix from the advertised autoconfiguration prefix in a
        Reachability TLV. This prefix is chosen at random, but may not collide
        with any prefix currently advertised within the network and therefore
        in the LSP database.</t>

If you would like I can change

This prefix is chosen at random, but may not collide with any prefix currently advertised within the network and therefore in the LSP database.

to read

In the absence of other considerations, this prefix is chosen at random. It MAY be derived from previous prefix allocation decisions, such as a prefix stored in nonvolatile memory, the prefix used by a previous pseudonode on the same LAN, or the subnet part of another prefix on the same interface. In any event, it MUST NOT collide with any prefix currently advertised within the network and therefore in the LSP database.

BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig draft says that an allocated prefix MUST be stored in non-volatile memory and as a result survive a reboot. Speaking for myself, I don't see the need for that; I'm not opposed to someone doing it, but they now have to think about "what happens when" for various kinds of network changes. I think the principle might be one of "least surprise"; if a certain prefix is in use on a LAN and the DIS changes (perhaps the old one fails), the new DIS should use the same prefix as the old one, so that the hosts don't have to jump through hoops. That said, I don't see the argument around a whole-building power failure; unless there is a server being advertised in DNS, a randomly-selected new prefix will work just as well as the old one.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2013 12:08:46 -0500

>>>>> "fred" == fred  <Baker (fred)" <[email-masked]>> writes:
    fred> If you would like I can change

    fred> This prefix is chosen at random, but may not collide with any
    fred> prefix currently advertised within the network and therefore
    fred> in the LSP database.

    fred> to read

    fred> In the absence of other considerations, this prefix is chosen
    fred> at random. It MAY be derived from previous prefix allocation
    fred> decisions, such as a prefix stored in nonvolatile memory, the
    fred> prefix used by a previous pseudonode on the same LAN, or the
    fred> subnet part of another prefix on the same interface. In any
    fred> event, it MUST NOT collide with any prefix currently
    fred> advertised within the network and therefore in the LSP
    fred> database.

I like.

---

From: james woodyatt <[email-masked]>
Date: Fri, 22 Feb 2013 13:11:40 -0800

> part might remain stable for a long time.

This problem is precisely why I campaigned bitterly and vigorously against the adoption and V6OPS and later the publication of RFC 6177.

When there was still a consensus that subscribers should always get a /48 prefix, it was reasonable to expect that a randomly chosen 16-bit subnet identifier would be unlikely to collide with another subnet in most automatically numbered routing domains.  We were also in a position to expect that when a subscriber adds a new prefix from the same or a different provider, that all the subnet identifiers in use on one prefix could be mapped 1:1 into the new prefix.  Now we have RFC 6177, which explodes all of that, for basically no sensible reason that I can see, and we are all the poorer for it.

Well done, V6OPS, well done.

--
james woodyatt <[email-masked]>
core os networking

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2013 08:15:45 +0000

On 22/02/2013 21:11, james woodyatt wrote:

> When there was still a consensus that subscribers should always get a /48 prefix

I think you must have missed the bit where operators and RIRs around the
world abandoned the /48 recommendation wholesale. 6177 simply recognised
reality.

I agree it's a shame, but it was not the IETF's doing.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2013 08:20:33 +0000

On 22/02/2013 16:54, Fred Baker (fred) wrote:

...
> BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig draft says that an allocated prefix MUST be stored in non-volatile memory and as a result survive a reboot. Speaking for my…

If Dynamic DNS Update is used, or some equivalent, even that issue would
go away. But I think that to the extent that IPv6 addresses will
ever appear on a user's screen, having stable values does have a small
benefit. Also see the issues raised in draft-ietf-6renum-static-problem,
some of which may apply in a homenet.

  Brian

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 23 Feb 2013 10:38:44 +0100

It might be a sidetrack on the discussion but I'll answer anyway

> Well done, V6OPS, well done.

As Brian said, it just reflect what RIR already has in place.

I was one of those that suggested and argued for the possibility of
using /56 for end-users, not only /48. However I still believe /48's
are great and I use it for most end-SITES. For end-USERS a /48 is
quite an overkill almost any way you consider it, except if you look
at it from a very overall point of view like in the situation this
mail-thread is about.
256 /64 is more than enough for almost all end-user cases I can dream
up. If any end-user have a setup where 256 LAN segments ain't enough,
well then it's so big that it should be consider a end-site and we are
back to /48.

The use case for homenet are those end-users, not end-sites. Or?

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 23 Feb 2013 22:24:23 +0000

> Well done, V6OPS, well done.

Two thoughts.

One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want castigate someone, castigate them.

Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant. We're discussing the ability to pick a half dozen at best out of a much larger field, and arguing against operators that can't see a reason for anything shorter than a /64. You've heard me argue before that prefix length should be an attribute of the service one purchases, much as capacity is: in the home, I suspect that a /60 would suffice for the vast majority of purposes, and I can imagine companies that would not be happy with a /56 but might be happy with a /52. I don't see a technical argument that everyone has to have precisely a /48.

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2013 08:54:46 -0800

Hi James,
At 13:11 22-02-2013, james woodyatt wrote:
>When there was still a consensus that subscribers should always get 
>a /48 prefix, it was reasonable to expect that a randomly chosen 
>16-bit subnet identifier would be unlikely to collide with another 
>subnet in most automatically numbered routing domains.  We were also

Architecture and politics do not go well together.  Some decisions 
tend to create complexity down the line.

Regards,
-sm

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Feb 2013 11:21:30 -0800

> One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want…

I'm unable to participate in ARIN or other RIR discussions, otherwise they would have heard a bellyful from me about it. I'd castigate *them* here too, but that would be off topic.

> Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant.

The point I wished to make is that we don't have a reasonable expectation that the size of a HOMENET subnet identifier will ever be constant over time and across renumbering events, much less across transfers between providers.  We're not even confident that a HOMENET will even be offered *any* space for a subnet identifier.

As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them.  Any HOMENET autoprefix system will depend on the proper configuration of a central subnet identifier registry integrated or tightly coupled with the border gateway. When new link routers arrive, they have to ask the central registry for the next available subnet identifier and take out a lease on it, just like an IPv4 host that has to maintain a lease to use its interface addresses with DHCP. When link routers leave, they have to release their lease or the network must wait for it to timeout.

And what happens when a HOMENET has four link routers in it, and the ISP renumbers the delegated prefix from a /60 to a /63?  Obviously, something in the network has to kick two of the routers out of the HOMENET, but which two?  Does the subscriber even get to choose?

Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution.  There are no good choices here, and the worst case outcome is that we will force the widespread adoption of NAT66 at HOMNET borders, precisely because it may turn out that subscribers want stable subnet identifiers, and more of them than their service providers are willing to provide at reasonable price.  This all happened before, and we're not showing any signs of making sure it doesn't happen again.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 25 Feb 2013 21:26:05 +0000

> Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution.  There are no good choices here, and the worst case outcome is that we will fo…

Here I'm a little confused. Who is "we"? To my knowledge, homenet hasn't given up on automated subnet allocation. If homenet has, no problem, let the draft expire.

If the ISP wants to allocate specific /64s to a customer, that's actually OK. It requires some thought, however. We are going to have to send a DHCP-PD request from each router in the network to the ISP's DHCP-PD server, which will allocate some number of /64s to the requesting router. I don't know about your world; in my world, it's not unusual for routers to have more than two interfaces; in a home using wireless and wifi, one could imagine each router asking for two downstream subnets just for that in addition to an upstream interface. The router in my home, a Cisco 881W, could conceivably have five subnets on as many interfaces in addition to whatever is on the ISP-facing interface.

I could imagine this requiring some jiggling of the DHCP-PD spec. As I recall, it (RFC 3633 section 10) allocates a prefix with a length, and allocates from that prefix to a variety of its own interfaces and potentially others. A router asking for 5 /64s will in fact ask for, and receive, one /61. If we want it to literally ask for a list of /64s, I think we have to play with it a bit. I suppose the IA_PD could contain multiple of those options; maybe that's the work-around.

What would actually be topical and helpful would be specific comments on the draft in question. What that it says do you object to, and what do you wish it would say?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 09:28:14 +0900

On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt <[email-masked]> wrote:

> As a result, it means that Automatic Prefix Management here is basically
> unable to do it statelessly, i.e. by randomly generating subnet numbers
> from an identifier space of conventional size and testing for collision
> before using them.
>

Why do you say this? Assuming the ISP(s) providing service to the home
assign enough space to number all the links (e.g., /60, /56, or /48), then
what's the problem?

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Feb 2013 18:22:50 -0800

On Feb 25, 2013, at 16:28 , Lorenzo Colitti <[email-masked]> wrote:
>> As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them.
> 
> Why do you say this? Assuming the ISP(s) providing service to the home assign enough space to number all the links (e.g., /60, /56, or /48), then what's the problem?

p1. I don't believe it's reasonable to assume that service providers will always provide a short enough prefix to number all the links in a subscriber's network, or that those that currently do will continue to do so into the foreseeable future, or that they will even give notice prior to reducing the space delegated to a subscriber.

p2. In a decent sized subscriber network, with several subnets in place, a /56 delegation means a small but significant changes that a randomly selected subnet identifier will collide with an existing one, whenever a router joins the network.  With a /60, the odds climb quite a bit, and in some networks it will be 15/16. (Do not make the mistake of assuming that router joins and leaves will be infrequent events. Plan for them happening several times per second, or you will be sorry later.)

p3. All this pain can be traded away for the reasonably well-understood pain of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier space, where collisions will be rare and stateless prefix autoconfiguration will settle quickly basically every time.  I personally don't think that's a good trade, but if routed home networks are ever to become the normal setup, then I'm very skeptical that my opinion will turn out to be the majority one.

I think if we want to avoid the temptation of subscribers to deploy NAT66 to preserve the stability of their 16-bit subnet identifier space in the face of service providers "enhancing their choices" with a variety of plans with varying policies for prefix delegation, then we have to do it with a stateful subnet manager in the network, near the border gateways.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Feb 2013 13:56:31 +1100

In message <[email-masked]>, james woodyatt wri
tes:
> p3. All this pain can be traded away for the reasonably well-understood pain 
> of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier spa
> ce, where collisions will be rare and stateless prefix autoconfiguration will
>  settle quickly basically every time.  I personally don't think that's a good
>  trade, but if routed home networks are ever to become the normal setup, then
>  I'm very skeptical that my opinion will turn out to be the majority one.

NAT66 assumes a /48 or else you don't have enough bits to fix the checksums.
 
> I think if we want to avoid the temptation of subscribers to deploy NAT66 to 
> preserve the stability of their 16-bit subnet identifier space in the face of
> service providers "enhancing their choices" with a variety of plans with var
> ying policies for prefix delegation, then we have to do it with a stateful su
> bnet manager in the network, near the border gateways.
> 
> 
> --
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 12:35:32 +0900

On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt <[email-masked]> wrote:

> p1. I don't believe it's reasonable to assume that service providers will
> always provide a short enough prefix to number all the links in a
> subscriber's network, or that those that currently do will continue to do
> so into the foreseeable future, or that they will even give notice prior to
> reducing the space delegated to a subscriber.
>

Ok, but in that case the only options available to us are a) give up, or b)
make routing work with smaller-than-/64 prefixes. I believe our current
plan is to give up and tell the ISPs that if they want to run a routed
home, then they need to assign it more than a /64.

The alternative is basically a vicious circle: if ISPs ignore the IETF's
advice and assign a /64 because they see additional address space as an
upsell opportunity, then someone will figure out how to share the /64 by
using ugly hacks like routing /128s assigned from DHCPv6. Goodbye privacy
addresses, goodbye robust routing, but still, things will work most of the
time. If the ISPs start to assign smaller than /64, things still work until
they assign fewer /128s than the number of devices you have. At that point,
someone will implement NAPTv6 and we're back where we started in IPv4.

> p2. In a decent sized subscriber network, with several subnets in place, a
> /56 delegation means a small but significant changes that a randomly
> selected subnet identifier will collide with an existing one, whenever a
> router joins the network.  With a /60, the odds climb quite a bit, and in
> some networks it will be 15/16. (Do not make the mistake of assuming that
> router joins and leaves will be infrequent events. Plan for them happening
> several times per second, or you will be sorry later.)
>

Ok, but isn't that why the prefix autoconfiguration drafts assume that
collisions are a regular part of prefix assignment? Are there issues with
those drafts? Will their approach not work?

> p3. All this pain can be traded away for the reasonably well-understood
> pain of NAT66 and a single ULA prefix with a constant 16-bit subnet
> identifier space, where collisions will be rare and stateless prefix
> autoconfiguration will settle quickly basically every time.
>

How is using a single ULA better for this? Perhaps you don't have to deal
with changes in flight (well, assuming that a backup router becomes
available to act as ULA anchor when the designated ULA anchor is
unplugged/crashes), so maybe that's a simplification. However, the moment
you try to use more /64s internally than you have externally, stateless
NPTv6 doesn't work any more, right?

For example, suppose you use fc00::/48 in the home, and you have two links,
which you number fc00:0:0:1::/64 and fc00:0:0:2::/64. You have one host on
each link, and for some reason they both pick the same interface ID, so
host A is fc00:0:0:1::dead:beef host B is fc00:0:0:2::dead:beef. Everything
works fine so far. Now suppose that externally you have only one /64,
2001:db8::/64. I can't see how that can work: if you get a packet
to 2001:db8::dead:beef, you don't know what to do with it.

I think if we want to avoid the temptation of subscribers to deploy NAT66
> to preserve the stability of their 16-bit subnet identifier space in the
> face of service providers "enhancing their choices" with a variety of plans
> with varying policies for prefix delegation, then we have to do it with a
> stateful subnet manager in the network, near the border gateways.

If you don't have enough external space for all your hosts, then a stateful
subnet manager isn't enough. You need a stateful host+port manager. i.e.,
you need an IPv4-style NAPT.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Feb 2013 22:46:15 -0500

On Feb 25, 2013, at 10:35 PM, Lorenzo Colitti <[email-masked]> wrote:
> The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6.

That might be what you imagine someone will do, but what they almost certainly will actually do is just bridge.   Math is hard.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 12:53:20 +0900

On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon <[email-masked]> wrote:

> using ugly hacks like routing /128s assigned from DHCPv6.
>
> That might be what you imagine someone will do, but what they almost
> certainly will actually do is just bridge.   Math is hard.
>

Yes, bridging will work because if everything is on one link, DAD will
avoid collisions. My point was that there is no way to do routing, even
with NPTv6, unless enough address space is assigned to the network.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 25 Feb 2013 21:54:39 -0800

Sent from ipv6-only Android
On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" <[email-masked]> wrote:
>> > The alternative is basically a vicious circle: if ISPs ignore the
IETF's advice and assign a /64 because they see additional address space as
an upsell opportunity, then someone will figure out how to share the /64 by
using ugly hacks like routing /128s assigned from DHCPv6.

Sorry for silly question. But ...is there a pointer to why routing is
desired in the home ?  Did homenet document usecases for this ?

Cb _______________________________________________

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 25 Feb 2013 22:01:08 -0800

Ok. I see it in the charter. I dont find it particularly appealing or worth
a great trade off for the level of complexity involved. Especially if the
tradeoffs require nat66 or something similarly complex

CB

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 07:10:42 -0500

On Feb 26, 2013, at 1:01 AM, Cameron Byrne <[email-masked]> wrote:
> Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex

Touché.

Seriously, though, the point of routing in the home is that you really don't want to bridge disparate media, and you want routers plugged together by people who don't know about routing to create a happy, functioning network, not a dysfunctional network that sort of works but is never satisfactory.

I'm sure Mark would give you a different sales pitch, but that's why I'm interested in it.

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Feb 2013 13:19:06 +0100

> Seriously, though, the point of routing in the home is that you really don't want to bridge disparate media, and you want routers plugged together by people who don't know about routing to create a…

exactly.

the arguments I've heard are:
 - people just plug in whatever they bought, it must work regardless of being a router or a bridge
 - not all link-layers can be bridged together e.g. 802.15.4
 - problems with bridging links with very different speed characteristics e.g. 802.11 and 1G wired
 - isolation between networks with different policy, e.g. guest networks, internal home automation, public wifi

cheers,
Ole

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 26 Feb 2013 18:30:44 +0000

> NAT66 assumes a /48 or else you don't have enough bits to fix the checksums.

You really need to re-read the document. https://tools.ietf.org/html/rfc6296

First, the term "NAT66" refers to stateful Network *Address* Translation, which doesn't update checksums in the prefix at all - it is what we have done in IPv4/IPv4 NAT but done in IPv6/IPv6 junction points, which means replacing the address entirely. If you're talking about stateless prefix translation, which can update the checksum in the prefix, it's Network Prefix Translation, NPT66. 

The reason we changed the name was that we couldn't get people to distinguish between those two notions; one blocks traffic while the other does not, and there are other ramifications. We obviously still have not succeeded.

NPT66 is not limited to /48s. It can update the checksum in the EID if the prefix is longer.

And then there's ILNP, which doesn't update the checksum in the translator because it changed the end to end checksum algorithm (the definition of the pseudo-header).

---

From: james woodyatt <[email-masked]>
Date: Tue, 26 Feb 2013 11:27:54 -0800

On Feb 25, 2013, at 19:35 , Lorenzo Colitti <[email-masked]> wrote:
> 
>  However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right?

Correct. But remember: I *never* write NAT66 when what I mean is NPTv6.  I really did mean NAT66 and not NPTv6.

In this scenario, we would number HOMENET domains with 16 bits of ULA subnet identifier and 64 bits of interface identifier for hosts on each subnet.  Then we would NAT66 the ULA /48 prefix into whatever addresses are in the pool of longer prefixes the service provider gives us because they won't give us a /48 at an acceptable price.  We would not use NPTv6, as that doesn't work.

We would then use the PCP protocol to control NAT66 mappings just the same as we do today with NAT44 mappings, but the good news is that PCP explicitly supports that form of IPv6/NAT so it's all good.  Thank you PCP working group.  Yes, this breaks referral in IPv6 even more than it's already broken, but I'm thinking service providers will be happy with that overall.

If I were building an IPv6 home gateway to support routed home networks today, this is how I would feel compelled to do it.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 26 Feb 2013 13:33:49 -0800

Sent from ipv6-only Android
On Feb 26, 2013 8:19 PM, "Ole Troan" <[email-masked]> wrote:
>
> >> Ok. I see it in the charter. I dont find it particularly appealing or
worth a great trade off for the level of complexity involved. Especially if
the tradeoffs require nat66 or something similarly complex
> >
> > Touché.
> >
> > Seriously, though, the point of routing in the home is that you really
don't want to bridge disparate media, and you want routers plugged together
by people who don't know about routing to create a happy, functioning
network, not a dysfunctional network that sort of works but is never
satisfactory.
>  - people just plug in whatever they bought, it must work regardless of
being a router or a bridge

How does routing make this better for a homenet ? Ethernet  supports
arbitrary topologies.

>  - not all link-layers can be bridged together e.g. 802.15.4

Whos requirement is that? Is it a primary use case or can be a stub L3 link

>  - problems with bridging links with very different speed characteristics
e.g. 802.11 and 1G wired

Routing is better?

>  - isolation between networks with different policy, e.g. guest networks,
internal home automation, public wifi

Seems like homenet is trying to devine the special sauce that makes
Frankenstein come alive.

Warning ... my home network includes exactly 1 802.11g AP that cost $50 6
years ago and effectively is Zero configuration.

CB

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 19:20:37 -0500

> Routing is better?
Yes.
> Warning ... my home network includes exactly 1 802.11g AP that cost $50 6 years ago and effectively is Zero configuration.
> 
You think it's zeroconf, but it's using DHCP on both ends.   It's not zeroconf, but it doesn't require configuration by you.   That is what we are trying to achieve here.   You aren't the only person who is skeptical, but the irony is that various people have demonstrated working models of key functionality, so the skepticism seems misplaced.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Feb 2013 23:52:01 -0500

>>>>> "james" == james woodyatt <[email-masked]> writes:
    james> Correct. But remember: I *never* write NAT66 when what I mean
    james> is NPTv6.  I really did mean NAT66 and not NPTv6.

    james> In this scenario, we would number HOMENET domains with 16
    james> bits of ULA subnet identifier and 64 bits of interface
    james> identifier for hosts on each subnet.  Then we would NAT66 the
    james> ULA /48 prefix into whatever addresses are in the pool of
    james> longer prefixes the service provider gives us because they
    james> won't give us a /48 at an acceptable price.  We would not use
    james> NPTv6, as that doesn't work.

If we must assume that the ISPs will be dorks, then I'd rather just
stick to triple-NAT'ed IPv4, and then the clueful people will get a
tunnel to sixxs or some place clueful.

I seem to recall that this is what we did with the ISDN, X.25 and the
rest of the incumbent carrier controlled protocols we had in the 1980s: we
used them as pipes for something decent.