Subject: [homenet] regarding recursive DHCPv6-PD

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Nov 2012 10:51:51 -0500

Clarifying my remarks at the mic...

Using PD in a home network isn't hard.  Use a single delegating router; most obvious choice is the device that received the prefix from the external source.

Every other router acts as a requesting router, and asks for a single /64 for each of its interfaces from the delegating router.

draft-baker-homenet-prefix-assignment-01 has more details.  Read it before you flame me.

*Recursive* PD is, indeed, harder.  Don't do it.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 10:53:47 -0500

> draft-baker-homenet-prefix-assignment-01 has more details.  Read it before you flame me.

Oh.  Yay!   I don't have to write a draft.   Thanks, Ralph!   (And thanks, Fred!)

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 7 Nov 2012 11:05:47 -0500

Nice.  Yes, that's a reasonable way to do that.

Recursive PD seems to inherently need some administrative input.  BTW, our switch implementation can do either.

Andrew

On 7/11/2012, at 10:51 AM, Ralph Droms <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 11:20:10 -0500

> Recursive PD seems to inherently need some administrative input.  BTW, our switch implementation can do either.

I don't see what admin input it requires.   The CPE edge router knows it's got a delegation, and signals to adjacent routers that it can act as a delegating router.   Routers that get /64 delegations know that they can't act as delegating routers, and instead act as relays to the CPE edge router.   This can all be done automatically.

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 7 Nov 2012 11:23:44 -0500

> I don't see what admin input it requires.   The CPE edge router knows it's got a delegation, and signals to adjacent routers that it can act as a delegating router.   Routers that get /64 delegatio…

But that's single-delegating-router, not recursive.  The problem with recursive is figuring out what prefix length a sub-delegating router is going to ask for from its upstream.  For a single-delegating-router setup, you just ask for either a bunch of /64s or something that just contains enough of those to cover all your downstream interfaces.  In a recursive situation, you don't know what you will need further downstream.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 18:32:59 +0100

On Nov 7, 2012, at 5:23 PM, Andrew McGregor <[email-masked]> wrote:
> But that's single-delegating-router, not recursive. 

What is a "recursive delegating router," and why do you want one?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 18:45:43 +0100

> What is a "recursive delegating router," and why do you want one?

So just in case this is a simple misunderstanding and not a new protocol proposal, what I said in my earlier message is that you don't need any sort of recursive setup.   The requesting router on the CPE, which gets a prefix that can be subdivided (i.e., not a /64) only ever gives out /64s downstream.   Any router on the net, regardless of where they are in the topology, gets prefixes from the CPE device with the big prefix, not from intermediate routers.  Intermediate routers that get /64 prefixes (which is how they know they are intermediate routers!) do not delegate—they relay to their delegating router if they get a PD from downstream.

I don't think there are actually any problems with this topology that require new protocol specs—I think this is purely an ops decision.   IOW, you could do this now with RFC3633.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 07 Nov 2012 12:53:59 -0500

>  Intermediate routers that get /64 prefixes (which is how they know they
>are intermediate routers!)

I am not sure I would agree that getting a /64 would inherently mean a
router knows is an intermediate router.  There are potential scenarios
where an edge router may get a /64 and be the ISP edge router (not the
best case scenario, but potential).

I know this subtle point is somewhat outside the context of this thread,
but just wanted to make the point.

Regards,

Victor Kuarsingh

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 7 Nov 2012 19:06:32 +0100 (CET)

On Wed, 7 Nov 2012, Andrew McGregor wrote:

> But that's single-delegating-router, not recursive.  The problem with 
> recursive is figuring out what prefix length a sub-delegating router is 
> going to ask for from its upstream.  For a single-delegating-router 
> setup, you just ask for either a bunch of /64s or something that just 
> contains enough of those to cover all your downstream interfaces.  In a 
> recursive situation, you don't know what you will need further 
> downstream.

For me, I've always taken for granted that the ISP CPE gets a /56 or 
something, and then it's fine to subdelegate /64s out of that as needed, 
and subdelegating routers request a /64 at a time as needed, and relay for 
sub-sub-delegating routers (as OP suggested).

The hard part is to get the source based routing to work so that packets 
flowing upstream exit via the correct ISP CPE (if the home is multihomed 
to multiple ISPs) depending on what source address they have, so as to 
avoid getting dropped by uRPF filters.

I'm surprised the subnet allocation size is still being discussed, I 
haven't followed the working group as closely as I should, but I hope we 
can get through this quickly.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 19:43:28 +0100

> but just wanted to make the point.

Such a router has no prefixes to delegate, so the distinction is immaterial.   There can only be one non-translating router on this network.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 07 Nov 2012 13:52:02 -0500

On 2012-11-07 1:43 PM, "Ted Lemon" <[email-masked]> wrote:

>Such a router has no prefixes to delegate, so the distinction is
>immaterial.   There can only be one non-translating router on this
>network.

This is why I said it's a point outside the context of the main discussion
(addressing within the homenet).

My point was more around what assumptions may be made by routers which do
in fact get a /64.  Assuming that routers in the homenet will likely be
using similar code (both those that show up on the edge and those which
are intermediate ones), other router functions may be automated, including
what mode of operation the router takes (edge vs. IR).  An example may be
security and/or filtering policy.

It's the assumption related to those other instances that had me worried.

Regards,

Victor Kuarsingh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 19:58:34 +0100

On Nov 7, 2012, at 7:52 PM, Victor Kuarsingh <[email-masked]> wrote:
> Assuming that routers in the homenet will likely be

In the solution I'm talking about, you don't use similar code—you use the _same_ code.   Realistically, CPE routers are all going to be essentially the same—there isn't going to be enough customer understanding to give rise to a market for second-hop homenet routers with different software.

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 7 Nov 2012 16:25:53 -0500

> What is a "recursive delegating router," and why do you want one?
In general, I don't think you do.

A recursive delegating router is one that will request a prefix, then load that as configuration into its own DHCP server and accept delegation requests from downstream, allocating out of that prefix.  It's feasible, but awkward.  You could instead, as I understood you were intending, run as a relay and forward downstream delegations instead.

I still think the OSPF solution is better for homenet.

Andrew

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Nov 2012 09:34:31 +0100

Well, being a residential CPE vendor, I can confirm some of our customers deploy /64 only to the CPE.
Not recommended by us, but being a managed CPE, it's the customer making the final decision on this.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: woensdag 7 november 2012 19:07
To: Andrew McGregor
Cc: [email-masked] Group; Ted Lemon; Ralph Droms
Subject: Re: [homenet] regarding recursive DHCPv6-PD

On Wed, 7 Nov 2012, Andrew McGregor wrote:

> recursive is figuring out what prefix length a sub-delegating router 
> is going to ask for from its upstream.  For a single-delegating-router 
> contains enough of those to cover all your downstream interfaces.  In 
> a recursive situation, you don't know what you will need further 
> downstream.

For me, I've always taken for granted that the ISP CPE gets a /56 or something, and then it's fine to subdelegate /64s out of that as needed, and subdelegating routers request a /64 at a time as needed, and relay for sub-sub-delegating routers (as OP suggested).

The hard part is to get the source based routing to work so that packets flowing upstream exit via the correct ISP CPE (if the home is multihomed to multiple ISPs) depending on what source address they have, so as to avoid getting dropped by uRPF filters.

I'm surprised the subnet allocation size is still being discussed, I haven't followed the working group as closely as I should, but I hope we can get through this quickly.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 10:48:02 +0100 (CET)

On Thu, 8 Nov 2012, Wuyts Carl wrote:

> Well, being a residential CPE vendor, I can confirm some of our 
> customers deploy /64 only to the CPE. Not recommended by us, but being a 
> managed CPE, it's the customer making the final decision on this.

If they only give the end user a /64, then the end customer won't be able 
to have a multi-LAN routed home. Hopefully the end customer will switch 
ISPs to one that isn't so restrictive.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 11:41:26 +0000

On 08/11/2012 09:48, Mikael Abrahamsson wrote:
>> customers deploy /64 only to the CPE. Not recommended by us, but being
>> a managed CPE, it's the customer making the final decision on this.
> 
> If they only give the end user a /64, then the end customer won't be
> able to have a multi-LAN routed home. Hopefully the end customer will
> switch ISPs to one that isn't so restrictive.

Fine, but when such an end customer buys a second router and plugs it in,
will she get an error message that says "Please find a new ISP"?

This is not intended as a frivolous question.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 07:05:15 -0500

> will she get an error message that says "Please find a new ISP"?

In this case I think our only option is to fall back to bridging.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 12:25:19 +0000

> In this case I think our only option is to fall back to bridging.

Without some fundamental surgery on the IPv6 specs, I fear that is true,
so does it have to become (gulp) a feature of the homenet architecture?

I would hate that but at the moment I see no alternative. There is
another alternative, routed ULA within the homenet and NPTv6 at the
border, but we've already said we don't want to recommend that.

I think the following paragraph of the architecture document needs
to be revised accordingly:

 The home network needs to be adaptable to such ISP policies, and thus
 make no assumptions about the stability of the prefix received from
 an ISP, or the length of the prefix that may be offered.  However, if
 only a /64 is offered by the ISP, the homenet may be severely
 constrained (with IPv6 not reaching all devices in the home, or use
 of some form of IPv6 NAT being forced), or even unable to function.
 While it may be possible to operate a DHCPv6-only network with
 prefixes longer than /64, doing so would break SLAAC, and is thus not
 recommended.

Something like:

 The home network needs to be adaptable to such ISP policies, and thus
 make no assumptions about the stability of the prefix received from
 an ISP, or the length of the prefix that may be offered.  However, if
 only a /64 is offered by the ISP, the homenet may be severely
 constrained. Attempting to use subnet prefixes longer than /64
 would break SLAAC, and is thus not recommended. Using ULA prefixes
 internally with NPTv6 at the boundary would be possible, but is not
 recommended for reasons given elsewhere. The least damaging solution
 would be for the internal routers to revert to bridging mode,
 even though this would destroy the benefits of subnetting.

    Brian

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 13:32:15 +0100 (CET)

> In this case I think our only option is to fall back to bridging.

Yes, doing protocol based brinding (L2 bridge 0x86dd packets) is the only 
way to go as far as I can tell.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 07:56:25 -0500

> so does it have to become (gulp) a feature of the homenet architecture?

I think it does, or the architecture becomes irrelevant because no-one will be brave enough to ship boxes that implement it.   And so we need to specify how it happens.

You are probably already aware that I strongly favor a routed ULA in the homenet (as opposed to the "keep using the ISP prefix after it expires kludge), but that doesn't solve this problem without NPTv6, which I think is a terrible idea.   Bridging preserves end-to-end; I think that's far more important than preserving subnetting.

That said, it would be nice if devices flashed a big red light or something if the ISP-delegated prefix is a /64.   I don't know of a way to specify that in the document, though.

Aside from the disagreement about ULA, I think your suggested modification to the text is right—the text as it is now recommends the wrong workaround to brokenness.

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 Nov 2012 13:57:38 +0100

> way to go as far as I can tell.

Um, er, ah, no, for many years now there has been the AHCP + babeld,
which routes /128s out of a /64 across any sort of wired/wireless
network over as many hops as needed.

I've been doing my best to ignore this discussion, and work on
improving that code.

You guys can beat your brains out over dhcp's approaches all you want,
and expect your ISPs in a cloudy future to deliver something bigger
than a /64 ...

and bridge low speed wifi over high speed ethernet all you want -

- but me, I kind of like being able to move transparently from AP to
AP and from wired to wireless and back again, and to not need anything
bigger than a /64 to do it.

Given the trends towards excessive dynamicism throughout the IPv6
deployment, and the naming issues, and various ways proposed to
monetize/make scarce /sub 64 allocations by the ISPS. I think the
market will pick ipv6 nat and something like AHCP.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Nov 2012 14:03:55 +0100

Well of course not.  Do you think they will be bothered by the fact that a second router (from another ISP) is not working properly ?  Please note, I'm talking about managed CPE, not retail, that's another model.

I do understand what you mean, but it is not that simple.  It is also very different in different countries.  Competition is different, price is key and some of them were told 20 years ago that the IPv4 address space was never going to be an issue, still they are hit with v4-shortage, so handle from a "safe" perspective.  And no, you don't have to convince me that there are plenty of v6 addresses, even when deploying /56 or something :-).  They often make a comparison:  deploying IPv4, you get a single public IPv4 address on the box, while doing nat and private IP's, typically some /24 in the LAN vs getting a /64 prefix for you own usage....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: donderdag 8 november 2012 12:41
To: Mikael Abrahamsson
Cc: [email-masked] Group; Andrew McGregor; Ted Lemon; Wuyts Carl; Ralph Droms
Subject: Re: [homenet] regarding recursive DHCPv6-PD

On 08/11/2012 09:48, Mikael Abrahamsson wrote:
>> customers deploy /64 only to the CPE. Not recommended by us, but 
>> being a managed CPE, it's the customer making the final decision on this.
> 

Fine, but when such an end customer buys a second router and plugs it in, will she get an error message that says "Please find a new ISP"?

    Brian

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Nov 2012 13:32:01 +0000

I don't think bridging should be considered for homenet. Don't forget 
the following in the charter:

"Also, link layer networking technology is poised to become more 
heterogeneous, as networks begin to employ both traditional Ethernet 
technology and link layers designed for low-powered sensor networks."

In a lot of these conversations, the "lightswitch guys" (as someone 
called the LLN proponents) seem to get forgotten.

Robert

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 14:41:48 +0100 (CET)

> called the LLN proponents) seem to get forgotten.

So let's just say that giving a single /64 to the home is incompatible 
with homenet architecture, and we need more addresses. I'm fine with that.

I see little reason to support /64 for homenet, because if there is only a 
single subnet, there is not much to network with within the home, there is 
only a single subnet.

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 08 Nov 2012 14:45:06 +0100

> called the LLN proponents) seem to get forgotten.
So what happens if the "lightswitch guys" want to plug-in a router, 
which they have to, as they can't bridge, but there's only one exit 
router from one ISP which is managed and gets a /64 only?
SLAAC relay? I think in this case a /64 is simply not acceptable.

Mat

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 14:09:58 +0000

> SLAAC relay? I think in this case a /64 is simply not acceptable.

OK, so there are failure cases and that too needs to be stated in the
architecture. Send text.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 14:17:38 +0000

On 08/11/2012 13:41, Mikael Abrahamsson wrote:
> I see little reason to support /64 for homenet, because if there is only
> a single subnet, there is not much to network with within the home,
> there is only a single subnet.

I wish I could agree. But if we don't provide for this situation in
the architecture, we are simply ignoring a segment of the real world,
and that is unrealistic. We need to design things so that if a homenet
user switches between a /56 ISP and a /64 ISP, stuff just reconfigures
itself to bridging mode (and any boxes that can't do that report the
problem in an intelligible way).

Also consider a dual-homed homenet where one ISP gives a /64 and the
other gives a /56. I guess that has to revert to bridging mode too.

    Brian

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Nov 2012 14:28:48 +0000

Comment inline.

Robert

>   even though this would destroy the benefits of subnetting.
<RCC>I think it is arguable whether bridging is the least damaging 
solution. It fundamentally does not work with route-over multi-link 
subnets and would therefore require some extra L2 weirdness at a LLN 
border router. If ISPs are going to hobble us with /64s then I think you 
will find NPTv6 solutions appearing for the same reason NAT is used 
today. There are alternatives but, as noted in the architecture draft, 
these break SLAAC. So I think the onus is to push back on ISPs ofering 
/64s if we want to avoid any kludges.</RCC>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 14:30:59 +0000

Dave,

> I've been doing my best to ignore this discussion, and work on

Code is good, but where is the spec that we can refer to? As far as
I can tell there's only an expired draft:
http://tools.ietf.org/id/draft-chroboczek-ahcp-00.txt
and RFC 6126, which is Experimental.

> and expect your ISPs in a cloudy future to deliver something bigger

Some ISPs will do that much sooner.

     Brian

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 Nov 2012 15:47:40 +0100

> and RFC 6126, which is Experimental.

In both cases the current open source code reflects the drafts, and
has been in production use for several years.

Since the initial babel rfc, two interoperable implementations of the
babel protocol have arisen in quagga-RE and quagga mainline, in
addition to the standalone babeld daemon.

Additionally, cryptographic authentication of selected routes is now
available both as running code in quagga AND as ietf draft, updating
but not superceding rfc 6126, draft was posted in august:

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-00

This makes it possible to withdraw certain networks from routing and
reduces the need for complex firewalling setups for ipv4 (natted or
non-natted) and ipv6.

Work is progressing on extending AHCP to do prefix distribution with a
similar algorithm to what is in the ospf version, but as noted,
shipping routed /128s around is simpler, and the default mechanism.

-- 
Dave Täht

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2012 16:02:57 +0100

HI,

> So let's just say that giving a single /64 to the home is incompatible with homenet architecture, and we need more addresses. I'm fine with that.

Yes please. I think some ISPs *need* to get a signal like this.
Sander

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 08 Nov 2012 10:09:07 -0500

>/64s if we want to avoid any kludges.</RCC>

Just to further some of the comments I made yesterday.  I understand the
we don¹t want a /64 to show up, but this may occur for reasons other then
the primary intention of the ISP.  Many things occur in a network - IP
depletion/low avail blocks, errors, mis-configuration etc.  No matter why
it occurs, ignoring this case is likely not a good idea.

I agree with earlier comments that this can be considered as a failure
mode.  It still needs to be considered for good engineering on how CPEs
and homenet gear will behave.

Regards,

Victor Kuarsingh

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 8 Nov 2012 15:11:04 +0000

What would happen today if a /64 showed up?  Why change that behavior?

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 08 Nov 2012 16:36:28 +0100

> other gives a /56. I guess that has to revert to bridging mode too.

I was going to suggest a solution, where the router within the homenet 
simply asks for a DHCP-PD, and if it gets one it keeps routing, 
otherwise it reverts to bridging. But if the homenet is dual-homed with 
a /64 and a /56, this would automatically exclude the /64 prefix from 
being used, ass the router would get a DHCP-PD from the /56 but not from 
the /64 and wouldn't even know that that /64 exists. But maybe that's a 
good thing unless the /56 points to a walled garden....
In that case a reachability test to a specific test router in the 
Internet could tell about the walled garden, and eventually force the 
router to put itself in bridging mode.

Mat

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 15:51:57 +0000

> and homenet gear will behave.

Exactly. It would be very bad for the end users to ignore this reality.

> Yes please. I think some ISPs *need* to get a signal like this.

Sure, but that does *not* excuse us from specifying how the end user
gets service in such a situation.

    Brian

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 08 Nov 2012 17:15:50 +0100

> OK, so there are failure cases and that too needs to be stated in the
So your text:

might become:

   The home network needs to be adaptable to such ISP policies, and thus
   make no assumptions about the stability of the prefix received from
   an ISP, or the length of the prefix that may be offered. However, if
   only a /64 is offered by the ISP, the homenet may be severely
   constrained. Attempting to use subnet prefixes longer than /64
   would break SLAAC, and is thus not recommended. Using ULA prefixes
   internally with NPTv6 at the boundary would be possible, but is not
   recommended for reasons given elsewhere. The least damaging solution
   would be for the internal routers to revert to bridging mode,
   even though this would destroy the benefits of subnetting.
   There are cases where neither bridging mode nor NPTv6, nor DHCPv6
   are feasible, e.g. if there are LLN subnets within the homenet
   which require remote access. In such cases a /64 assignment from
   an ISP will break the home network, and should therefore be avoided.

Feel free to rewrite it.

Mat

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Nov 2012 16:57:30 +0000

Mat,

That looks good to me, I hope the architecture authors will pick it up.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 13:58:58 -0500

An ISP that gives out a single /64 is broken.  As long as we have a way
to indicate "out of /64s" (because that could happen, even if you are
given a /48, and have some pathology...), then we are good.  

A home may have multiple ISPs, and people are gonna notice that some of
them work better than others.  Further, routing in the home is gonna
work even if the ISP is lame.

The market will notice, and will decide.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 14:00:57 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Also consider a dual-homed homenet where one ISP gives a /64
    Brian> and the other gives a /56. I guess that has to revert to
    Brian> bridging mode too.

no.  Let's let the /56 work well, and let the /64-ISP break.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 14:04:22 -0500

>>>>> "Mattia" == Mattia Rossi <[email-masked]> writes:
    >> In a lot of these conversations, the "lightswitch guys" (as
    >> someone called the LLN proponents) seem to get forgotten.

    Mattia> So what happens if the "lightswitch guys" want to plug-in a
    Mattia> router, which they have to, as they can't bridge, but
    Mattia> there's only one exit router from one ISP which is managed
    Mattia> and gets a /64 only?  SLAAC relay? I think in this case a
    Mattia> /64 is simply not acceptable.

The lights work in the home (because routing of ULA works fine)
Possibly, you can't control them from outside the home.  So, ISP that
gives out /56 has an obvious way to demonstrate why they suck less than
/64-only ISP.

It is not clear that all LLNs will even want globally routable address
space.  Some will. Some won't know what to do with it.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 14:07:07 -0500

>>>>> "Mattia" == Mattia Rossi <[email-masked]> writes:
    Mattia> might become:

    Mattia>   The home network needs to be adaptable to such ISP
    Mattia> policies, and thus make no assumptions about the stability
    Mattia> of the prefix received from an ISP, or the length of the
    Mattia> prefix that may be offered. However, if only a /64 is
    Mattia> offered by the ISP, the homenet may be severely
    Mattia> constrained. Attempting to use subnet prefixes longer than
    Mattia> /64 would break SLAAC, and is thus not recommended. Using
    Mattia> ULA prefixes internally with NPTv6 at the boundary would be
    Mattia> possible, but is not recommended for reasons given
    Mattia> elsewhere. The least damaging solution would be for the
    Mattia> internal routers to revert to bridging mode, even though
    Mattia> this would destroy the benefits of subnetting.  There are

I am opposed to this text.

    Mattia> cases where neither bridging mode nor NPTv6, nor DHCPv6 are
    Mattia> feasible, e.g. if there are LLN subnets within the homenet
    Mattia> which require remote access. In such cases a /64 assignment
    Mattia> from an ISP will break the home network, and should
    Mattia> therefore be avoided.

please remember that multicast is hostile to plain wifi, and regularly
breaks it, if you bridge wired to wireless.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 14:11:18 -0500

>>>>> "Leddy," == Leddy, John <[email-masked]> writes:
    Leddy> What would happen today if a /64 showed up?  Why change that
    Leddy> behavior?

An RFC6204 router with a single LAN interface is perfectly happy getting
a /64.

An RFC6204 router with more than one LAN interface that doesn't get
enough address space:

   WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.

it doesn't tell us to start bridging.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 14:17:24 -0500

>> Yes please. I think some ISPs *need* to get a signal like this.

    Brian> Sure, but that does *not* excuse us from specifying how the
    Brian> end user gets service in such a situation.

so, lets' say you come home with a new fancy router... and you discover
that haven't got an electrical outlet to plug it into.

Should we solve that problem too?
(as homework: are power bars NAT's, Routers, or Bridges?)

-- 
Michael Richardson
-on the road-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 14:28:22 -0500

> it doesn't tell us to start bridging.

Sure, but "log a system management error" is not something that a home router vendor can meaningfully implement, unless it puts a speaker in the home router and has it start bellowing "out of addresses" in every known language.

But the real problem is that this signal, even if received, will be misinterpreted as "router is broken, return to Home Despot and replace with one that isn't broken."

---

From: Ray Bellis <[email-masked]>
Date: Thu, 8 Nov 2012 19:40:17 +0000

> But the real problem is that this signal, even if received, will be misinterpreted as "router is broken, return to Home Despot and replace with one that isn't broken."

<no hat>

I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration.  In particular, they warn you if you try to use double NAT.

Users can acknowledge those warnings, so they no longer appear.

I can envisage a box issuing a similar warning if it only gets a /64 from its upstream.

It would be nice if there was a generic method for doing this that was vendor independent, but I guess that's unlikely to happen.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 14:56:17 -0500

> I note that the Apple Airport Utility pops up warnings about various errors, some of which relate to sub-optimal network configuration, rather than misconfiguration.  In particular, they warn you i…

This is very cool, but even people I know who have Airport base stations frequently have no idea what to do about these warnings, and most people don't have Airport base stations—they have stupidly cheap Linsky routers.

---

From: Hans Liu <[email-masked]>
Date: Fri, 9 Nov 2012 04:03:20 +0800

> I can envisage a box issuing a similar warning if it only gets a /64 from its upstream.

As a CPE vendor, I don't think I'd design my product this way. I won't
have my router to issue a warning if it only gets a /64 from its
upstream. The reason?  Users see a warning in either log or LED, they
call either the operator or my customer service.  I really don't want
to say so but the one that will face a problem is the downstream
router, and that's not my problem.

Sincerely,
Hans

-- 
Instead of following the fashion, we lead it through.

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 8 Nov 2012 15:21:08 -0500

This whole thread is making me think that specifying that we use either babel (with attention to getting it documented properly) or one of the OSPFv4 MANET extensions, in the case where we have only a /64 and perhaps any time we find we have an 802.11s, ad-hoc or NBMA interface in play.  That way we introduce /128 routes, and everything continues to work.

Andrew

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Nov 2012 20:40:49 +0000

Just to be clear - using a /64 will not necessarily break a home network 
with a LLN. It's just that some kludge will be needed  and the least 
preferable IMHO for LLNs is bridging.

So I would suggest something like:

"The home network needs to be adaptable to such ISP policies, and thus 
make no assumptions about the stability of the prefix received from an 
ISP, or the length of the prefix that may be offered. However, if only a 
/64 is offered by the ISP, the homenet may be severely constrained. 
Attempting to use subnet prefixes longer than /64 would break SLAAC, and 
is thus not recommended. Using ULA prefixes internally with NPTv6 at the 
boundary would be possible, but is not recommended for reasons given 
elsewhere. Another solution would be for the internal routers to revert 
to bridging mode, even though this would destroy the benefits of 
subnetting and has serious limitations with regard to heterogeneous link 
layer technologies and LLNs."

Robert

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 8 Nov 2012 20:48:49 +0000

Can this be generalized for anytime a prefix offered is not large enough
to cover the number of interfaces?

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Nov 2012 20:49:56 +0000

Independent of the routing protocol, I don't think we want to inject a /128 advertisement for every device in the homenet into the homenet routing domain.
Acee

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 8 Nov 2012 16:40:36 -0500

Oops, meant to reply to the list the first time...

I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 16:44:37 -0500

> I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal.

+1

I realize that I've been arguing for a different solution, but I agree that this is better.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Nov 2012 22:09:08 +0000

>> I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal.

Is a few hundred enough to meet the present and future homenet requirements?

---

From: Simon Kelley <[email-masked]>
Date: Thu, 08 Nov 2012 22:51:29 +0000

> I realize that I've been arguing for a different solution, but I agree that this is better.

For the stragglers, is this backwards compatible with existing devices? 
Will my Android phone, which expects to do DHCPv4 and SLAAC in one or 
more IPv6 /64s, connect unmodified to such a network?

Simon.

---

From: Mattia Rossi <[email-masked]>
Date: Fri, 09 Nov 2012 09:00:34 +0100

> gives out /56 has an obvious way to demonstrate why they suck less than
This is exactly the message that should be conveyed by the draft
> space.  Some will. Some won't know what to do with it.
I agree on that. That's why I took the case where they want globally 
routable addresses to remote control each single light (or sensor - 
which might sound more plausible to some folks). If the lights just need 
to communicate within the homenet, ULA's do the job. And as you say, 
they might even be the better solution.

---

From: Mattia Rossi <[email-masked]>
Date: Fri, 09 Nov 2012 09:10:54 +0100

Am 08.11.2012 21:40, schrieb Robert Cragie:
> Just to be clear - using a /64 will not necessarily break a home 
> network with a LLN. It's just that some kludge will be needed  and the 
> least preferable IMHO for LLNs is bridging.
>
Yes, I agree, and you can't force the LLN routers to be some high-end 
routers able to do all the necessary magic to work around the problems 
due to the assignment of a /64 from the ISP.
> ISP, or the length of the prefix that may be offered. However, if only 
> a /64 is offered by the ISP, the homenet may be severely constrained. 
> Attempting to use subnet prefixes longer than /64 would break SLAAC, 
> and is thus not recommended. Using ULA prefixes internally with NPTv6 
> at the boundary would be possible, but is not recommended for reasons 
> given elsewhere. Another solution would be for the internal routers to 
> revert to bridging mode, even though this would destroy the benefits 
> of subnetting and has serious limitations with regard to heterogeneous 
> link layer technologies and LLNs."
>
I prefer your text :-)

Mat

---

From: Mattia Rossi <[email-masked]>
Date: Fri, 09 Nov 2012 09:19:57 +0100

> router, and that's not my problem.
Your CPE router could be the downstream router. The user buys it, plugs 
it in, doesn't work. No warning, nothing.
He throws it out, even if it's not your fault, and never buys anything 
from your company again.
How's that for a scenario?

Mat

---

From: Hans Liu <[email-masked]>
Date: Fri, 9 Nov 2012 10:16:25 +0000

Sent from Hans' iPad2

On Nov 9, 2012, at 4:20 PM, "Mattia Rossi" <[email-masked]> wrote:

> Your CPE router could be the downstream router. The user buys it, plugs it in, doesn't work. No warning, nothing.
> He throws it out, even if it's not your fault, and never buys anything from your company again.

If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a fore-coming downstream router attached to me.

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Nov 2012 13:37:28 +0100

Op 9 nov. 2012, om 09:00 heeft Mattia Rossi het volgende geschreven:

> I agree on that. That's why I took the case where they want globally routable addresses to remote control each single light (or sensor - which might sound more plausible to some folks). If the lights just need to communicate within the homenet, ULA's do the job. And as you say, they might even be the better solution.

I expect a controller, with global address. This enables control from outside. 
Other solution: VPN for back to my home.

Teco

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Nov 2012 08:48:30 -0800

> given a /48, and have some pathology...), then we are good.

Does that apply to my Android phone too?

Mike

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Nov 2012 14:54:34 -0500

> I note that the Apple Airport Utility pops up warnings about various
> errors, some of which relate to sub-optimal network configuration,
> rather than misconfiguration.  In particular, they warn you if you try
> to use double NAT. 

it seems to me that we ought to ask Apple^WStuart how these warnings are
communicated from AirPort to laptop, and ask them if they would like to
contribute a document to homenet to standardized such a protocol.

(are they in DHCP? RAs? mDNS? something weirder?)

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Nov 2012 14:56:37 -0500

>>>>> "Andrew" == Andrew McGregor <[email-masked]> writes:
    Andrew> This whole thread is making me think that specifying that we
    Andrew> use either babel (with attention to getting it documented
    Andrew> properly) or one of the OSPFv4 MANET extensions, in the case
    Andrew> where we have only a /64 and perhaps any time we find we
    Andrew> have an 802.11s, ad-hoc or NBMA interface in play.  That way
    Andrew> we introduce /128 routes, and everything continues to work.

so, great maybe, except that now either:
1) hosts have to participate in the routing protocol. (so impact on
   hosts)

2) we have to deploy proxy-ND.

(and that's why RPL isn't on the table at homenet)

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Nov 2012 18:19:39 -0500

>>>>> "Teco" == Teco Boot <[email-masked]> writes:

    >>> Possibly, you can't control them from outside the home.  So, ISP
    >>> that gives out /56 has an obvious way to demonstrate why they
    >>> suck less than /64-only ISP.

    >>> It is not clear that all LLNs will even want globally routable
    >>> address space.  Some will. Some won't know what to do with it.

    >> I agree on that. That's why I took the case where they want
    >> globally routable addresses to remote control each single light
    >> (or sensor - which might sound more plausible to some folks). If
    >> the lights just need to communicate within the homenet, ULA's do
    >> the job. And as you say, they might even be the better solution.

    Teco> I expect a controller, with global address. This enables
    Teco> control from outside. Other solution: VPN for back to my home.

In a simple home, the controller is on the one LAN which got the /64,
and so that side of it is accessible anyway.  

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Nov 2012 18:21:54 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    >> An ISP that gives out a single /64 is broken.  As long as we have
    >> a way to indicate "out of /64s" (because that could happen, even
    >> if you are given a /48, and have some pathology...), then we are
    >> good.

    Michael> Does that apply to my Android phone too?

Are you asking if your Android phone, when it gets only /64 from LTE/3G
provider, should hand that out, and then indicate "out of /64s"? Yes.

The phone has a pretty clear way to indicate this problem to the user.

-- 
Michael Richardson
-on the road-

---

From: mike <[email-masked]>
Date: Fri, 09 Nov 2012 15:30:34 -0800

> The phone has a pretty clear way to indicate this problem to the user.
I'm asking about whether I should expect my android phone to get a /56.
My phone is, after all, capable of being a router. I'm somehow guessing that
phone isp's aren't giving out /56's though.

Mike

---

From: Robert Cragie <[email-masked]>
Date: Sat, 10 Nov 2012 01:21:15 +0000

> (and that's why RPL isn't on the table at homenet)
<RCC>Why not? Again, the sort of networks which would use RPL (LLNs) are 
referred to in the charter.</RCC>

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 10 Nov 2012 06:20:31 -0800

> phone isp's aren't giving out /56's though.

This case is looked at in v6ops
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03

The simple answer is that there is a deployment lag issue. Neither Android
nor the mobile networks support PD today. But they can and will support pd
in time.

CB

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 10 Nov 2012 09:52:59 -0500

Proxy-ND doesn't seem hard... much less evil than NAT, after all.

Andrew

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Nov 2012 07:03:51 -0800

Cameron Byrne wrote:
> 
> On Nov 9, 2012 3:30 PM, "mike" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The simple answer is that there is a deployment lag issue. Neither 
> Android nor the mobile networks support PD today. But they can and will 
> support pd in time.

I expect that there well may be resistance as wireline-ISP's have come to expect that
there's a "router" in home. I very much doubt they view phones as anything other than
hosts except when they can charge outrageous fees for "tethering".

Which sort of brings up the obvious question: if ISP's don't cooperate, what will
people do to route around the damage, especially in the face of all the unused space
of a /64 they can poach.

Mike

---

From: Teco Boot <[email-masked]>
Date: Sat, 10 Nov 2012 16:26:05 +0100

> phone isp's aren't giving out /56's though.

Maybe. Maybe not.
My phone supports three tethering interfaces already. My provider supports 
tethering. No IPv6 yet. Any idea how multi-interface tethering is supported 
with single /64, without proxy-ND, without translation?

We could stop writing how /64 could work, with hacks. Better describe the 
clean way of doing, and publish lots on bad things that happen with /64 PD 
to customers.

Teco

---

From: Mattia Rossi <[email-masked]>
Date: Mon, 12 Nov 2012 15:05:03 +0100

> If I'm the downstream router, I can't get a prefix, of course I issue warning message. However, if I'm the one who still get an /64 and works fine as a leaf, I won't issue an warning message for a…
So you have to implement a check and some sort of warning mechanism for 
not getting a PD anyways in all your devices (as I suspect that all of 
them could eventually be used as a "downstream" router). I don't think 
that it's much more difficult to check whether the PD was for a /64. You 
have to do that anyway, as your DHCP server won't be able to create a PD 
from a /64 and issue a warning in any case. So actually no real extra 
work needed there.

<non technical reason start>
The problem with having just the downstream router warning you though, 
is that in the case of multihoming, and two prefixes being provided to 
the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream 
router might get them over the same interface, and simply issue no 
warning, as it's happy with the /56 from ISP2, and route everything over 
that ISP, without the user ever knowing. If the upstream router issues a 
warning about getting a /64 over an interface from an ISP, the user 
knows there's something wrong and can fix things, and avoid unnecessary 
high bills.
</non technical reason end/>

After the input of various posts I'd like to change the text in 3.4.1:

to the following text:

    The home network needs to be adaptable to such ISP policies, and thus
    make no assumptions about the stability of the prefix received from
    an ISP, or the length of the prefix that may be offered.  However, if
    only a /64 is offered by the ISP, the homenet may be severely
    constrained. Attempting to use subnet prefixes longer than /64
    would break SLAAC, and is thus not recommended. Using ULA prefixes
    internally with NPTv6 at the boundary would be possible, but is not
    recommended for reasons given elsewhere. Reverting to bridging would
    destroy subnetting, breaks multicast if bridged onto 802.11 wireless
    networks and has serious limitations with regard to heterogeneous
    link layer technologies and LLNs. For those reasons it is recommended
    that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning
    upon receipt of a /64 if required to assign further prefixes within
    the home network as described in Section 3.4.3.

Mat

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:15:50 -0500

>>>>> "mike" == mike  <[email-masked]> writes:
    >> The phone has a pretty clear way to indicate this problem to the user.

    mike> I'm asking about whether I should expect my android phone to get a /56.
    mike> My phone is, after all, capable of being a router. I'm somehow guessing that
    mike> phone isp's aren't giving out /56's though.

So far, they aren't giving out anything.  Perhaps we can encourage 3G
"terminals" to be able to be configured as to how much address space
they ask for.... a nice slider :-)

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:16:45 -0500

>>>>> "Andrew" == Andrew McGregor <[email-masked]> writes:
    Andrew> Proxy-ND doesn't seem hard... much less evil than NAT, after all.

I concur.  I am not sure why there has been so much concern about it.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:18:38 -0500

>>>>> "Mattia" == Mattia Rossi <[email-masked]> writes:
    Mattia> to the following text:

    Mattia> The home network needs to be adaptable to such ISP policies, and thus
    Mattia> make no assumptions about the stability of the prefix received from
    Mattia> an ISP, or the length of the prefix that may be offered.  However, if
    Mattia> only a /64 is offered by the ISP, the homenet may be severely
    Mattia> constrained. Attempting to use subnet prefixes longer than /64
    Mattia> would break SLAAC, and is thus not recommended. Using ULA prefixes
    Mattia> internally with NPTv6 at the boundary would be possible, but is not
    Mattia> recommended for reasons given elsewhere. Reverting to bridging would
    Mattia> destroy subnetting, breaks multicast if bridged onto 802.11 wireless
    Mattia> networks and has serious limitations with regard to heterogeneous
    Mattia> link layer technologies and LLNs. For those reasons it is recommended
    Mattia> that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning
    Mattia> upon receipt of a /64 if required to assign further prefixes within
    Mattia> the home network as described in Section 3.4.3.

+1

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:19:02 -0500

+1

-- 
Michael Richardson
-on the road-

---

From: Mark Townsley <[email-masked]>
Date: Mon, 12 Nov 2012 12:47:59 +0100

On Nov 10, 2012, at 2:21 AM, Robert Cragie wrote:

> <RCC>Why not? Again, the sort of networks which would use RPL (LLNs) are referred to in the charter.</RCC>

In the charter, LLNs are referred to as an example of a link-layer which might exist in the home and would accordingly require its own routed subnet, not that the entire home itself will be an LLN.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 12 Nov 2012 18:33:56 +0100

Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you.

I'm concerned with any "issue a warning" type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either. 

If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply,  "no IPv6" for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here. 

- Mark

On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote:

> So you have to implement a check and some sort of warning mechanism for not getting a PD anyways in all your devices (as I suspect that all of them could eventually be used as a "downstream" router). I don't think that it's much more difficult to check whether the PD was for a /64. You have to do that anyway, as your DHCP server won't be able to create a PD from a /64 and issue a warning in any case. So actually no real extra work needed there.
> 
> The problem with having just the downstream router warning you though, is that in the case of multihoming, and two prefixes being provided to the homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might get them over the same interface, and simply issue no warning, as it's happy with the /56 from ISP2, and route everything over that ISP, without the user ever knowing. If the upstream router issues a warning about getting a /64 over an interface from an ISP, the user knows there's something wrong and can fix things, and avoid unnecessary high bills.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 19:03:09 -0500

>>>>> "Mark" == Mark Townsley <[email-masked]> writes:
    Mark> I'm concerned with any "issue a warning" type suggestions
    Mark> though. We are working hard to develop automatic configuration
    Mark> that assumes there is no operator involved here. If there is
    Mark> no operator to configure our protocols, there is no operator
    Mark> to issue a warning to either.  

okay.
Can we define a DHCP "request", which is really a request for the ISP to
log something from that customer?  i.e. can we tunnel syslog through
dhcp?   :-)

Or shall we suggest homenet routers ask the ISP for a syslog server,
and log things there?  (do we have a dhcp option to describe syslog
server...  a grep of RFCs doesn't find one, and rfc5424 doesn't mention
one) 

In particular, for ISP provided routers, this would make lots of sense.

-- 
Michael Richardson
-on the road-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Nov 2012 08:24:20 +0000

> If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply,  "no IPv6" for that given link. Falling back to the user to…

Which is a FAIL if there are any v6-only devices around. Ultimately I don't see
how you can avoid some kind of warning to the user, even if it's the equivalent
of the beeping from a smoke detector whose battery is fading.

   Brian

---

From: Robert Cragie <[email-masked]>
Date: Tue, 13 Nov 2012 13:09:47 +0000

+1 to Brian. Falling back to the user left with a broken connection and 
no feedback is not acceptable. Short cryptic messages may be terse at 
the point of origin but there is no lack of resources on the internet to 
elucidate them.

Robert

---

From: Robert Cragie <[email-masked]>
Date: Tue, 13 Nov 2012 13:20:43 +0000

Mark,

I agree with what you say but that still means RPL could be on the 
table. It seems quite feasible to me that we could have a multi-link 
route-over subnet using a routing protocol such as RPL with downstream 
border routers as well. This may seem unlikely with an LLN but is more 
feasible with broader band link layer technologies. Granted, if 
multi-link route-over subnets are considered to exist only as "leaf 
subnets" (i.e. without downstream border routers) then life does get 
somewhat easier. The question is whether that is acceptable or not for 
the general picture.

Robert

On 12/11/2012 11:47 AM, Mark Townsley wrote:
> In the charter, LLNs are referred to as an example of a link-layer 
> which might exist in the home and would accordingly require its own 
> routed subnet, not that the entire home itself will be an LLN.
>
> - Mark
>
>>
>>
>>>
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Nov 2012 08:14:52 -0600

On Nov 13, 2012, at 2:24 AM, Brian E Carpenter <[email-masked]> wrote:
> even if it's the equivalent

To which the typical response is to throw the damned thing through the window out of rage after it's been beeping for a couple of hours.

No, there are several viable solutions to this problem that don't involve beeping.   Beeping is not the right solution.

I would just like to point out, regarding the bufferbloat problem, that there are two classes of outcome if we hack around this problem instead of beeping.

The first class of outcome is that something works less well than it otherwise would have.   This is the bufferbloat problem.   If you have bufferbloat because you set up a bridge where ideally you shouldn't have, this is bad, and the customer will experience less than ideal outcomes.   But fundamentally, their network will function, particularly when loads are light.   And so this becomes a problem that they will either live with, or try to solve, but it is not an emergency.   It is a bad outcome, and the villain is clear: it's the ISP who gave out a /64.   FAQs on the net can cast the blame appropriately, and the home gateway can provide diagnostics that explain why the situation is suboptimal.

Contrast this with NAPTv6.   In this case, the network is _broken_.   End to end doesn't work.   If you are not connected directly to the border gateway, certain protocols simply will not work.   The result of this will be a general expectation on the part of applications vendors that end-to-end isn't something that can be counted upon.   And so we will have got nothing for all our effort in deploying IPv6.   We'll be back to NAT-inspired walled gardens.

Let's at least set our sights on the better outcome: the one that preserves end to end.   Yes, it's not ideal.   But the blame will be cast on the correct villain, the end-user will at least have a chance of a good outcome, and it won't needlessly break end-to-end.

---

From: Mattia Rossi <[email-masked]>
Date: Tue, 13 Nov 2012 16:50:24 +0100

> Let's at least set our sights on the better outcome: the one that preserves end to end.   Yes, it's not ideal.   But the blame will be cast on the correct villain, the end-user will at least have a…
I still like the idea of a led which is red if no prefix could be 
received, orange if a /64 has been assigned, and a prefix has been 
requested from a downstream router (no prefix for the downstream 
router), and green if a prefix < /64 has been assigned and a prefix has 
been requested from a downstream router and successfully provided.
This is like the leds on the smoke detector, which start blinking once 
the battery level is low. They signal a problem, but it's up to the user 
whether to ignore it, or to fix it.
Additionally, if there's no prefix request from a downstream router, no 
warning will be issued (e.g. green led) as there's no problem.
Dual homed networks with a /64 from one provider and a /56 from the 
other might actually behave the same.
As the /64 part gets a prefix request, it switches to orange led, even 
though the prefix can be provided by the /56 part, and subnetting works. 
But it's a partial bad outcome, and the user should get a hint at that.
Up to him then to leave it or fix it.

I can understand that it would be almost out of scope to put such a 
mechanism/idea should into the draft, as it should focus on how to 
magically solve issues.
I'm just afraid that even if you put in phrases like "a /64 will 
seriously limit the functioning of the homenet" twenty times in the 
draft, it might get ignored by ISPs, and thus would love to have the 
suggestion of issuing some sort of warning by the gear vendors written 
somwhere.

Just my 2c

Mat

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 08:01:20 -0800

> of the beeping from a smoke detector whose battery is fading.

I too am bothered quite a lot by the notion that nothing will ever go wrong
therefore we don't have to plan for it. With the complexity of networks being
contemplated here, I think the likelihood that they will self-organize and just
"work" completely unattended in all/most cases asymptotically approaches zero.
We simply have no empirical evidence that any such thing has ever been done,
and plenty of evidence that even given huge amounts of networking clue that
awful things happen awfully often.

What really bothers me is that routers are treated as "others": the notion that
normal people are not just expected to have no clue about networking, but
that they should be actively prevented from gaining clue by interacting with
their infrastructure. I really think that's wrongheaded. While I think that a
beeping box is a horrible idea, I wouldn't be adverse to my box, say, sending
me email alerting me to what is wrong, and how I might fix it. There are probably
many other ways to deal with this too, and the problem isn't limited to routers
but all headless boxen -- though routers may have some unique properties.

Mike

---

From: Dave Taht <[email-masked]>
Date: Tue, 13 Nov 2012 17:27:01 +0100

On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas <[email-masked]> wrote:
>>> I'm concerned with any "issue a warning" type suggestions though. We are
>>> working hard to develop automatic configuration that assumes there is no
>>> operator involved here. If there is no operator to configure our protocols,
>>> there is no operator to issue a warning to either.
>>>
>>> If the homenet runs out of /64s to hand out, and we recommend not to
>>> route /128s, bridge, NPTv6, etc... then the final option is, simply,  "no
>>> IPv6" for that given link. Falling back to the user to try and interpret a
>>> cryptic message about IPv6 prefixes is simply not a realistic option for the
>>> protocols we are working on here.
>>

+1

One of the innovations in cerowrt is that it includes a mini-jabber
server, to which a given user could subscribe, for critical messages.

-- 
Dave Täht

---

From: Mark Townsley <[email-masked]>
Date: Tue, 13 Nov 2012 18:22:18 +0100

> server, to which a given user could subscribe, for critical messages.

My mother doesn't know how to subscribe to jabber. You might reach her by having the router be her friend and sending a status update via facebook though.

I'm not against next-gen management interfaces, or sending messages or giving config knobs to users that understand what they mean. I think some of the new products that let you manage your home router from your iphone or android device are fantastic for the average user. When a guest came to my house recently, I pushed a few buttons on my iPhone which sent him a text message with all he needed to connect to the guest SSID. I could have let him take a picture of a QR code on my iPhone as well. Or tapped his NFC compliant device with a little card that came with the router. Or pressed two buttons. There are all sorts of ways to configure a router these days. All good.

But remember we're just one layer here. If each and every thing a router did thought it was so self-important that it could communicate with the user whenever it liked, imagine how much SPAM that might produce. Do you remember some of the cryptic dialog boxes you used to get from PC software 10 years ago? True story: I once got flooded with emails from random America Online users all over the world because the company that wrote the AOL networking stack that came on the AOL CD-ROMs threw up a dialog box with L2TP in the message. At the time, when you typed L2TP into the AOL search engine, you got the RFC and my email address. People sent me email asking why their AOL wasn't working. 

Each and every part of the router must do everything it can to work without bugging the user. it's enough work to bother them for the *really* important stuff like "do I let this device on the network?", "do I allow connectivity with my neighbor", etc.  

- Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Nov 2012 12:16:53 -0600

On Nov 13, 2012, at 9:50 AM, Mattia Rossi <[email-masked]> wrote:
> I still like the idea of a led which is red if no prefix could be received, orange if a /64 has been assigned, and a prefix has been requested from a downstream router (no prefix for the downstream router), and green if a prefix < /64 has been assigned and a prefix has been requested from a downstream router and successfully provided.
> This is like the leds on the smoke detector, which start blinking once the battery level is low. They signal a problem, but it's up to the user whether to ignore it, or to fix it.

I've got no argument with a notification mechanism like that, as long as we provide a clean mechanism for dealing with the case where the ISP doesn't provide as many bits of prefix as we need.

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Nov 2012 10:28:16 -0800

Given the "complexity" of a potential home net, a complexity that is often alluded to on the mail list (including below), there will no doubt be "policy" that has to be introduced - a policy language or facility that can be described or communicated by an end user, preferably without technical jargon.  This policy language, or "facility" could also offer options for how the user(s) of the home net would want to be notified in the event of any exceptions.

Randy

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Nov 2012 10:33:06 -0800

Hi All,

I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a "/64" assigned to a home network is considered to be potentially "constrained" somehow ?

Thanks,
Randy

---

From: Simon Kelley <[email-masked]>
Date: Tue, 13 Nov 2012 20:35:56 +0000

On 13/11/12 18:33, Randy Turner wrote:
>
> Hi All,
>
> I've been away from the list for awhile, and am trying to catch up --
> is there a reference or quick explanation as to why a "/64" assigned
> to a home network is considered to be potentially "constrained"
> somehow ?
>

Because no IPv6 network can be smaller than /64 and have stateless 
autoconfiguration work. To have routed subnets in the homenet requires 
one /64 prefix per subnet, and a /64 prefix cannot be subnetted - it is 
already the smallest legal subnet.

Simon.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Nov 2012 13:05:42 -0800

> Each and every part of the router must do everything it can to work without bugging the user. it's enough work to bother them for the *really* important stuff like "do I let this device on the netw…

That and motherhood and apple pies. But then your home network melts
down. Then what?

I'll say again: we have no experience at all with mass deployment of complex
zero-touch networks. In fact, we have no experience at all with mass deployment
of anything other than flat networks with clients only. As Jim Getty's points out,
we do have some experience with accidentally complex networks with poor to
non-existent means to whip them back into submission and it's not pretty.

Mike

---

From: james woodyatt <[email-masked]>
Date: Tue, 13 Nov 2012 14:47:34 -0800

> I've been away from the list for awhile, and am trying to catch up -- is there a reference or quick explanation as to why a "/64" assigned to a home network is considered to be potentially "constra…

Once upon a time [RFC 3177], we believed that creating a numbering plan for subscriber networks was intolerably difficult and expensive, so we thought it would be a very good idea to make sure every new subscriber of any size would a /48 delegation, which we all thought was big enough for all but the most titanic of organizations.  The idea was you'd get enough space up front that you could take your numbering plan with you if you ever moved from one provider to another.  Space was thought to be too cheap to meter, and the benefit of number plan stability across providers was thought to be beneficial.

Since then, we have discovered two things: A) service providers guard with astonishing ferocity every last number they get from their registries even when they are too cheap to meter, and B) the problem of number plan scaling is one that only people without any money have any interest in seeing solved.  Hence, we have a new recommendation from IAB [RFC 6177], which capitulates on the one-size-fits-all recommendation. It also says this in section 2:

   However, this precludes the expectation that even home sites will
   grow to support multiple subnets going forward.  Hence, it is
   strongly intended that even home sites be given multiple subnets
   worth of space, by default.  Hence, this document still recommends
   giving home sites significantly more than a single /64, but does not
   recommend that every home site be given a /48 either.

For my part, I have a hard time foreseeing how the expectation that residential sites will always have more space to assign than a single /64 subnet is even remotely reasonable.  Far too many service providers are casting into operational concrete topologies that assign only one subnet to each billable subscriber gateway.

I don't hold out much hope that much of a market will ever exist for residential networks with multiple subnets per subscriber.  I also don't hold out much hope for the kind of coordination between service providers that will permit multihomed residential sites to work well.

That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway.

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

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 13 Nov 2012 21:09:46 -0500

On 2012-11-13 5:47 PM, "james woodyatt" <[email-masked]> wrote:
>
>For my part, I have a hard time foreseeing how the expectation that
>residential sites will always have more space to assign than a single /64
>subnet is even remotely reasonable.  Far too many service providers are
>casting into operational concrete topologies that assign only one subnet
>to each billable subscriber gateway.

I can't speak for all operators, but I would say most I have dealt with do
not specifically suggest that a single /64 is the target.

That said, there are current operation considerations which factors into
the present Wireless and Wireline network prefix assignments.  This has
caused situations where a single /64 is given out or made available for
now.

In the longer term, I would think that shorter prefixes would be handed
out.  There is no guarantee how large of a prefix will be provided - This
is likely an operator to operator decision (but market demand normally
dictates the eventual outcome).

>
>I don't hold out much hope that much of a market will ever exist for
>residential networks with multiple subnets per subscriber.  I also don't
>hold out much hope for the kind of coordination between service providers
>that will permit multihomed residential sites to work well.

I don't agree that operators are not considering multi-subenet home
networks.  I know of at least one which is looking at more.  As for
co-ordination between operators, I suspect this is subject to traditional
behaviours (no reason to assume character will change for IPv6)

>
>That's why it looks to me like HOMENET will eventually converge on
>specifying single /64 links behind a single residential gateway.

I personally would not like to see HOMENET confine the work to a single
/64.  I do however think the group needs to consider the fact that a
gateway MAY get a /64 (a sad, but perfectly valid PD) for any number of
reasons- therefore it needs to be considered in how the HOMENET treats the
situation.

Regards,

Victor K

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Nov 2012 18:34:18 -0800

I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough - and if this prefix is "globally available" on the internet, I think it's much more than the ISPs can get their heads around, at least for now.

I understand the limitations of stateless autoconfig and other constraints, but I would start with something like a /64, but with a capability that allows multiple /64 prefixes (or other method for SLAAC) to be added later without a forklift upgrade or re-thinking of what we do first.  Each home site "could" subnet this space, so we could include any new work on MDNSEXT or other name resolution that is decentralized but can cross subnets.

I don't think we would be short-changing potential uses for home net by taking IPv6 "baby steps" for now….given that the ISPs and consumer home networks are not even as advanced as the multi-service IPv4 home network business models we were trying to sell to LECs/CLECS/ISPs when I was at 2Wire back in 2000.

I (for one) would be thrilled if I could get an IPv6 /64 that is globally visible (not NAT'd) from my ISP.  It's so much more than I have today.

Randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Nov 2012 06:20:40 +0100 (CET)

On Tue, 13 Nov 2012, james woodyatt wrote:

> residential sites will always have more space to assign than a single 
> /64 subnet is even remotely reasonable.  Far too many service providers 
> are casting into operational concrete topologies that assign only one 
> subnet to each billable subscriber gateway.

Then those need to re-think their decisions.

> hold out much hope for the kind of coordination between service 
> providers that will permit multihomed residential sites to work well.

Why do you believe we need coordination between service providers to 
permit multihomed services to work well? I thought the whole idea was to 
handle multiple upstream prefixes and make sure everything is routed to 
the correct ISP?

> specifying single /64 links behind a single residential gateway.

I hope not.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Nov 2012 06:28:15 +0100 (CET)

On Tue, 13 Nov 2012, Mattia Rossi wrote:

> I still like the idea of a led which is red if no prefix could be received, 
> orange if a /64 has been assigned, and a prefix has been requested from a 
> downstream router (no prefix for the downstream router), and green if a 
> prefix < /64 has been assigned and a prefix has been requested from a 
> downstream router and successfully provided.

This sounds like a reasonable compromise. I am not a vendor manufacturer 
though, don't know the cost of this.

> This is like the leds on the smoke detector, which start blinking once the 
> battery level is low. They signal a problem, but it's up to the user whether 
> to ignore it, or to fix it.

I don't know if it's local requirements, but my smoke detectors start 
chirping once every 5 minutes or so when they're low on battery. I don't 
want my home gateway to start doing that :P

---

From: joel jaeggli <[email-masked]>
Date: Tue, 13 Nov 2012 21:30:35 -0800

On 11/13/12 9:20 PM, Mikael Abrahamsson wrote:

> permit multihomed services to work well? I thought the whole idea was 
> to handle multiple upstream prefixes and make sure everything is 
> routed to the correct ISP?

If coordination is required, it's not going to work.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Nov 2012 08:17:53 +0000

On 13/11/2012 21:05, Michael Thomas wrote:
>> Each and every part of the router must do everything it can to work
>> without bugging the user. it's enough work to bother them for the
>> *really* important stuff like "do I let this device on the network?",
>> "do I allow connectivity with my neighbor", etc.
>>
> 

Right. And we're creating a new profession here: "Home Network Guru".
I think that's inevitable, and there needs to be some way of telling
the user "Call your guru".

(It's surprising what Google finds today when you type in homenet error.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Nov 2012 09:31:02 +0000

On 14/11/2012 02:34, Randy Turner wrote:
> I was thinking that, in an effort to reduce scope to something we can deal with for now, that a /64 would be big enough

It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever.

    Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 14 Nov 2012 09:57:36 -0500

> That's why it looks to me like HOMENET will eventually converge on specifying single /64 links behind a single residential gateway.

I think Homenet should not make the assumption that the different 
networks are from a larger block like /5x but rather a collection  /64's.
Think about the dual ISP connection case, the ISPa/xx allocated blocks 
is quite likely to be disjoint from the ISPb/yy allocated blocks,
and xx != yy is quite possible.

	Olafur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Nov 2012 09:07:39 -0600

> It simply isn't, because it doesn't allow subnetting in the home/car/small office or whatever.

I don't see the point in working on the /64 case—if that's all we're trying to accomplish, we've already accomplished it.   The interesting work Homenet is doing is in fact trying to solve the prefix distribution and automatic setup problem.   It's true that this is a hard problem.   It's also true that if we don't specify a solution, people will attempt to solve it in their own ways.   And if they do that, we will wind up in the situation that Jim found himself in with his broken box with its own built-in DHCP server.

BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case.   IPv6 deliberately places the multi-homing case in-scope.   This creates a bit of a problem for legacy apps that do not support multi-homing, but it also creates the winning situation that if one device is advertising a provisioning domain that doesn't work, applications that do correctly handle multi-homing will simply use a different provisioning domain.

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 16:48:15 +0100

> BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case.   IPv6 deliberately places…

Yes, this is the use case I'm interested in. I don't think it is to hard to get there, as long as we don't try to hide the more complex network topology and DHCP facilities from hosts. We must be backward compatible, but should not block enhancements.

Teco

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Nov 2012 07:58:07 -0800

> BTW, a little more on that topic: the reason that two DHCP servers on the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle the multi-homing case.   IPv6 deliberately places…

I'm guessing the main problem wasn't multihoming per se: they were both
probably giving out 192.168 addresses, which would be a problem in v6
were it to happen too. And of course even if they didn't collide, it could
still be a problem if the rogue dhc were pointing the host to a router that
doesn't have the route the dhc says it does.

But the real question I have is: what constitutes a "legacy app"? How
do I know if I've written one or not?

Mike

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 17:09:57 +0100

> doesn't have the route the dhc says it does.

I say the routers do run a protocol that support multihoming. The current direction is routing based on source and destination address (or destination and source, order is less important here). Hosts may send packets to whatever router. It is important that correct interface is selected. This is a MIF topic.

> do I know if I've written one or not?

More important: how to write non-legacy apps that do provide the more enhanced robustness. Or upgrade the stack, as mptcp.

Teco

---

From: Randy Turner <[email-masked]>
Date: Wed, 14 Nov 2012 09:27:00 -0800

Have their been any ISPs that have come forward to discuss their consumer IPv6 allocation plans?  I don't think we should wrap ourselves around a model that says, "yeah, we need multiple /64s for consumers because that's the way a particular protocol works (SLAAC).   Maybe we need another method. One /64 for a home network seems like overkill regarding address space utilization -- A /32 would be overkill.  I know some folks think we have more address space than we'll ever use, but gee….

Randy

---

From: Randy Turner <[email-masked]>
Date: Wed, 14 Nov 2012 10:24:50 -0800

Meant to say a 32-bit address space for the home would be more than enough…:)

R.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Nov 2012 19:28:28 +0100 (CET)

On Wed, 14 Nov 2012, Randy Turner wrote:

> Have their been any ISPs that have come forward to discuss their 
> consumer IPv6 allocation plans?  I don't think we should wrap ourselves 
> around a model that says, "yeah, we need multiple /64s for consumers 
> because that's the way a particular protocol works (SLAAC).  Maybe we 
> need another method. One /64 for a home network seems like overkill 
> regarding address space utilization -- A /32 would be overkill.  I know 
> some folks think we have more address space than we'll ever use, but 
> gee….

Personally I don't see a way we can get anything deployed in any near time 
if we abandon or try to change SLAAC. I don't see it as productive either.

/64 is what we have to work with. /56 per household scales perfectly well 
when doing the math.

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 15 Nov 2012 07:40:46 +1300

I have a /48 at home, on a retail ISP, right now.  I know, one data point does not a trend make, but it is a proof by example that some ISP is doing that.

Andrew

---

From: Randy Turner <[email-masked]>
Date: Wed, 14 Nov 2012 10:58:11 -0800

I'm not against one or more  /64 bit prefixes for a home net, if everyone else (including the ISPs) think that home networks should be able to scale up to 18,446,744,073,709,551,615 hosts, I'm completely on board.  It's not my resource, so I'll take all they give me.  :)  It would be nice to have an AT&T, Verizon, or some other major provider chime in to say they're on board with the assumptions we're making.  Maybe they already have, I've been away from the list for awhile, or maybe they've indicated this allocation strategy in some other forum.  I'm old school and I'm not used to having publicly routable address space to burn.

Randy

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Nov 2012 12:49:37 -0800

On Nov 13, 2012, at 21:30 , joel jaeggli <[email-masked]> wrote:
>> Why do you believe we need coordination between service providers to permit multihomed services to work well? I thought the whole idea was to handle multiple upstream prefixes and make sure everything is routed to the correct ISP?
> 

Let's put on our thinking caps.  Say I have a HOMENET with two provider-provisioned border gateways, each from different providers.

Let's call them ALFA Broadband and BRAVO Networks.  Say that ALFA delegates 2001:db8:aaaa::/64 to me and BRAVO delegates 2001:db8:bbbb::/64 to me (yes, they could delegate shorter prefixes, but let's say I have only one link to number, so the prefixes above are the ones that each gateway will be advertising in Router Advertisement messages on my HOMENET link).

When they're both up and running, each router is a default gateways on my link.  Each host gets two prefixes on the link, i.e. 2001:db8:aaaa::/64 and 2001:db8:bbbb::/64 and a default router list comprising both the gateways for ALFA and BRAVO.

Given how the hosts in the field today behave, only one of the routers will be forwarding outbound packets.  Which is fine.  Let's say my gateway from ALFA is the default router all my hosts always pick, i.e. it's at the front of the default router list. Now let's say a host on my network chooses to connect to a remote destination where source address selection rules say that it should pick an address from the BRAVO prefix delegation.  The SYN packet with source address 2001:db8:bbbb::XXXXX goes to the ALFA router.  What does it do with that?

- Does it forward the packet?  If so, then the return path will be asymmetric, i.e. it will come back through my BRAVO gateway.  Asymmetric paths are the reason 6to4 anycast is broken.  I thought we learned our lesson about that.  Maybe not all of us did, but I bet we soon will if we keep going this road.

- Does it recognize the 2001:db8:bbbb::/64 prefix and redirect to the BRAVO router?  If so, then how does it know to do that?  Coordination, because routers don't process Router Advertisements, so the ALFA gateway won't have reason to know about the BRAVO prefix unless it makes an exception to the standard rules.  I'm not optimistic that the players involved will have any incentive to adopt protocols that enable that happen.    This all sounds very squirrelly to me, and the incentives to do it seem completely missing in action.

(By the way, how do you redirect a whole prefix?  You don't.  How do you cancel a redirection?  You don't.  How do we fix this?  By getting 6MAN to revise Router Advertisements and rolling out new host implementations everywhere.  Good luck with that.  Oh but wait: maybe, the ALFA router doesn't redirect, but it forwards instead.  Path asymmetry again— just not as badly asymmetric as it would otherwise be, i.e. asymmetry is confined to the local link.)

Maybe I'm missing something, but I think this is really an intractable problem, given what I know about it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Nov 2012 22:34:29 +0100 (CET)

> problem, given what I know about it.

Having outgoing packets from ALFA prefix go out to ALFA and BRAVO prefix 
to go out via BRAVO has been on the problem description for over a year 
(afaik), so I can't imagine people aren't looking into that already.

It's not solved by ISPs coordinating, that's never going to happen. I've 
always seen it to be solved via some kind of source based routing 
automatically discovered between the ISP routers. I believe this is in the 
suggestions already. uRPF is well known problem that needs to be handled.

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Nov 2012 14:44:39 -0800

On Nov 14, 2012, at 13:34 , Mikael Abrahamsson <[email-masked]> wrote:
> 
> I've always seen it to be solved via some kind of source based routing automatically discovered between the ISP routers.

My point is that it isn't sufficient to handle this problem at just the routers.  At a minimum, the *hosts* need to be told which default router to use with each source prefix.  Right now the only mechanism that comes close to doing that is ICMPv6 Redirect, which isn't suitable for addressing this problem.

This problem might not be so troubling if hosts didn't expect any and all of the default routers on a link either to forward packets with source addresses having prefixes they don't advertise, or to send a redirect for the destination to one that will.

Alas, hosts do have such an expectation, and that's not going to change any time soon.

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Nov 2012 18:48:02 -0800

On Nov 14, 2012, at 17:22 , Michael Richardson <[email-masked]> wrote:
> 
>    james> My point is that it isn't sufficient to handle this problem
>    james> at just the routers.  At a minimum, the *hosts* need to be
>    james> told which default router to use with each source prefix.
>    james> Right now the only mechanism that comes close to doing that
>    james> is ICMPv6 Redirect, which isn't suitable for addressing this
>    james> problem.
> 
> the edge routers can fix things for the hosts.

If they coordinate.

Section 3.2.4 Multihoming of I-D.ietf-homenet-arch-06 goes into some detail about the challenges in the scenario under discussion in this thread, and it mentions two proposals by name:

  I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat
  I-D.baker-fun-multi-router

Neither of which sufficiently answers my open questions about how multiple provider-provisioned subscriber gateways will coordinate forwarding of packets to the correct egress for their source prefix.  Please don't misunderstand: I can imagine a routing protocol that could do what I-D.baker-fun-multi-router describes, more or less-- it would display the local path asymmetry I described previously, but that might not be a deal-killer.

What I can't imagine is that operators of provider-provisioned subscriber gateway equipment will have any incentive to deploy such a routing protocol, and I can imagine several ruthless and selfish reasons for them to resist.

For starters, imagine this scenario: I'm an unhappy customer of ALFA Broadband, which is the largest incumbent carrier in my region, and I want to add the scrappy local underdog bargain provider, BRAVO Networks, as an egress to my existing HOMENET installation, so I can be multi-homed while I renumber and transition from one service provider to another.  When I sign up with BRAVO, they have to ask me: is this a new HOMENET, or do you have an existing HOMENET routing domain we need to join.

If I tell BRAVO it's a new HOMENET, then I don't get be to be multihomed with ALFA because their equipment won't forward packets with ALFA's source address either to ALFA's router or to the global Internet.  Sadness. Must tell them about the existing HOMENET installation then.

If I tell BRAVO it's an existing HOMENET, then I can only be multihomed if I can also get ALFA's router to admit BRAVO's new router to the routing domain it serves, but ALFA provisioned the thing and configured it for me. It's a crude black box as far as I'm concerned, and that's just how both they and I like it.  So, to complete this migration, I now have to call up ALFA and say to them, "Hi, I just signed up with your competitor, and I'd like for the router you installed for me, with whatever firmware it's running, to cooperate with their new router, running who knows what, in the HOMENET routing domain you set up for me years ago when I first signed up.  Would you please reconfigure?  Kthxbai!"

Any guesses what their response is likely to be?

I'm honestly not sure how we expect this to work.  It seems, either A) I have to be a highly technical mediator between ALFA Broadband and BRAVO Networks for the coordination of any HOMENET routing domain for which they're both going to provide access service, or B) they have to communicate directly with one another. Neither alternative seems very practical to me.

> this has been discussed on this list extensively.

Without apparent resolution or the production of a draft as far as I can see.  Hence my ongoing skepticism about this usage scenario.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Nov 2012 21:00:45 -0600

> My point is that it isn't sufficient to handle this problem at just the routers.  At a minimum, the *hosts* need to be told which default router to use with each source prefix. Right now the only m…

This is at least notionally a very easy thing to do, since the source address they are using is in a prefix that they configured on the basis of a router advertisement.   When would it make sense to send a packet with that source address to any router other than the one that advertised that prefix?

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Nov 2012 19:41:39 -0800

On Nov 14, 2012, at 19:00 , Ted Lemon <[email-masked]> wrote:
> 
> When would it make sense to send a packet with that source address to any router other than the one that advertised that prefix?

What if there are many millions of hosts already in the field today, which currently choose the default router at the head of their priority-ordered default router list, regardless of whether that router's previous advertisements ever included a Prefix Information option with remaining preferred lifetime?

However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider.

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 06:56:16 +0100

There are a few proposals on the table, that let the routers solve the problem. Legacy hosts can send the packet to router ALFA or BRAVO. Misdirected packets, say packets with source address from ISP ALFA send to BRAVO are redirected to router ALFA. Such forwarding should not trigger an ICMP REDIRECT, as the forwarding was on source address. ICMP REDIRECT are applicable for guiding packets forwarded on destination address.

Teco

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Nov 2012 08:16:42 +0000

On 14/11/2012 22:44, james woodyatt wrote:
> My point is that it isn't sufficient to handle this problem at just the routers.  At a minimum, the *hosts* need to be told which default router to use with each source prefix. 

Of course. I suggested this when MIF started out, and it's a MIF
issue still.

   Brian

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 15 Nov 2012 11:19:00 +0100

On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
[email-masked]> wrote:

> >> I've always seen it to be solved via some kind of source based routing
> automatically discovered between the ISP routers.
> >
> >
> > My point is that it isn't sufficient to handle this problem at just the
> routers.  At a minimum, the *hosts* need to be told which default router to
> use with each source prefix.
>

The hosts do already select the correct router depending on the prefix.
They're tied together. An RA contains a prefix and router address. That's
what the host keeps in memory.
If it's two RA's one router becomes default, the other more specific. The
host/applications will also only use one prefix at a time, thus always send
the packets down the correct path.
In my experience it was always the same prefix, the one that got registered
first (if no preference was setup in the advertising router).
If the host is connected via two or more interfaces (so we're in MIF area
now), there will always be one preferred prefix, and interface, and the
outgoing routing will work.
If applications are able to chose a specific prefix (e.g. VPN) they usually
implement some source routing on the host anyways, and send the packets to
the router registered with that prefix.
If you have an application listening for incoming connections, then it's
important that the application is smart enough to use the address on which
the incoming connection arrived as source address, and not the default one
which might be on a different prefix to avoid asynchronous communication.
As far as I know this is already common practice. So I don't really see a
problem here, unless you want to do some fancy load sharing and play ping
pong with source addresses.
If there's only one interface which connects to a multihomed router, the
principle is the same, but the multihomed router must be able to perform
source address routing, and forward the packets down the right path. And
this is something I'm not too sure about routers can currently do.
Mat

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Nov 2012 11:51:31 +0100

> This is at least notionally a very easy thing to do, since the source address they are using is in a prefix that they configured on the basis of a router advertisement.   When would it make sense t…

exactly. that's rule 5.5 in RFC6724.
when there are intermediate routers between the host and the border routers the routers need to use SADR (source address dependent routing).

all we can do in the IETF is to write documents. I think RFC6724 is sufficient, but please correct me if I'm wrong.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Nov 2012 12:20:06 +0100 (CET)

> exactly. that's rule 5.5 in RFC6724.

Looking at 5.5, I don't see how we could design anything at all that 
relies on 5.5 working. It's not even a SHOULD or a MUST as far as I can 
tell?

> all we can do in the IETF is to write documents. I think RFC6724 is 
> sufficient, but please correct me if I'm wrong.

It's my opinion that we can't rely on 5.5 working. Hosts need to not 
support 5.5 and things should still work.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Nov 2012 12:09:36 +0000

> what the host keeps in memory.

Where is that specified? And what if the network is using DHCPv6
to provide such information?

The strongest statement I can find in RFC 6724 about this is a
MAY in section 7, which doesn't make this predictable.

> If it's two RA's one router becomes default, the other more specific. 

The two might be of equal standing and both offer a route to ::/0.

> The

I don't believe that is fully specified either. Each new socket
might make a new choice.

> outgoing routing will work.

Then why is MIF still arguing?

> the router registered with that prefix.

Sure, but we are worried here about zero-conf defaults.

> As far as I know this is already common practice. 

Not good enough - it needs to be specified.

> So I don't really see a

Indeed. Again, this needs specifying, as does behaviour when
there are multiple routers and one of them receives a packet
that should exit via another one.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2012 07:26:13 -0500

> However notionally easy this problem is to address, I imagine that practical matters, at some point, must rise to the top of the pile of points to consider.

Those hosts are broken.   They can't work in a multi-homed environment.   Millions of hosts is very close to zero.   Do you want to wait to solve this problem until there are billions?

Most of those hosts are Macs, iOS devices and Android devices, which can be upgraded easily and are upgraded frequently (at least according to the stats I follow).   So please just fix this bug in iOS and MacOS, instead of arguing that the situation is hopeless.

We are building a network protocol suite for the future, not the present.   IPv4 was broken in various ways when it was at the stage of deployment IPv6 is at.   Measures were not taken to solve some of its problems in the IETF, and as a consequence ugly hacks were done in the field to work around these problems.

It is not our job to prognosticate about what might get deployed.   It is to try to figure out what should get deployed.   It is perfectly okay if what we propose takes ten years to see widespread deployment.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2012 07:27:58 -0500

On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson <[email-masked]> wrote:
> It's my opinion that we can't rely on 5.5 working. Hosts need to not support 5.5 and things should still work.

Why do hosts need to not support 5.5?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Nov 2012 13:31:38 +0100 (CET)

>From RFC6724:

"Discussion: An IPv6 implementation is not required to remember
       which next-hops advertised which prefixes.  The conceptual models
       of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
       have no such requirement.  Hence, Rule 5.5 is only applicable to
       implementations that track this information."

So since 5.5 is not a MUST (and most hosts today do not support 5.5 as far 
as I know), designing HOMENET based on 5.5 support on all hosts seems 
misdirected.

... or what am I missing?

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Nov 2012 13:39:09 +0100

Mikael,

> So since 5.5 is not a MUST (and most hosts today do not support 5.5 as far as I know), designing HOMENET based on 5.5 support on all hosts seems misdirected.
> 

how do you want it to work?

the tools we have currently are:
 - ICMP redirect
 - ICMP type 1, code 5
 - DHCP option for SAS/DAS policy
 - RFC6724 rule 5.5
 - RFC4191

what is missing?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Nov 2012 13:54:20 +0100 (CET)

> - DHCP option for SAS/DAS policy

In my mind, I was looking at a new mechanism that the ISP routers used to 
tell each other what prefix they were advertising and handing out.

I couldn't find specifics on "DHCP option for SAS/DAS policy", so I don't 
know what that means exactly. Could you give a pointer? If I read 
<https://github.com/otroan/IETF-CPE-router/wiki> my guess is that it is 
more for the homenet router when they get DHCPv6-PD, but I might be 
mistaken?

But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather 
solve getting the correct traffic to the correct ISP router on the ISP 
router level, not in the hosts. So no ICMP redirects, just source based 
routing between the ISP routers.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Nov 2012 14:04:30 +0100

Mikael,

> In my mind, I was looking at a new mechanism that the ISP routers used to tell each other what prefix they were advertising and handing out.

the kind of do with http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-03

but you can't a) expect the ISP routers to be able to discover each other (might not be on the same link), b) operated by the same entity.

> I couldn't find specifics on "DHCP option for SAS/DAS policy", so I don't know what that means exactly. Could you give a pointer? If I read <https://github.com/otroan/IETF-CPE-router/wiki> my guess is that it is more for the homenet router when they get DHCPv6-PD, but I might be mistaken?

https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/
this is more for multi-homing to non-congruent networks.

> But relying on RFC6724 rule 5.5 for all hosts seems unfeasable. I'd rather solve getting the correct traffic to the correct ISP router on the ISP router level, not in the hosts. So no ICMP redirects, just source based routing between the ISP routers.

we're not, the RFC6724 rule only applies when a host is connected to two routers with different upstream connectivity.
inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border.

the only thing we're asking for here is that the hosts also do a simplified form for SADR when directly connected to multiple border routers.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Nov 2012 14:21:49 +0100 (CET)

On Thu, 15 Nov 2012, Ole Trøan wrote:

>> In my mind, I was looking at a new mechanism that the ISP routers used 
>> to tell each other what prefix they were advertising and handing out.
>

b) I never imagined, a) would be nice if that could be solved. I don't see 
any text in that draft regarding source based routing though.

> inside the home, i.e the host is behind two internal home routers, SADR is used to get to the correct border.

What happens if the host doesn't support 5.5?

> the only thing we're asking for here is that the hosts also do a 
> simplified form for SADR when directly connected to multiple border 
> routers.

So, I still can't find anything about a mechanism for routers in homenet 
for network-wide discovery of where a certain src address packet should be 
sent when it's destined for the default route (to the Internet).

Why can't OSPF be used (needs new functionality) so that all homenet 
routers learn a default-route per prefix, and thus have multiple default 
routes, and select which one to use depending on what the src address is 
of the packet? That would relieve the hosts of having to do anything at 
all (it is nice if they can do 5.5, but things wouldn't break without it). 
Basically "multi-topology" but instead of being one for IPv4 and one for 
IPv6, we now have one topology per ISP allocated prefix.

Or am I missing things again?

I would really like to avoid requiring functionality in the hosts as I see 
this as a big obstacle to get homenet implemented in real life.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Nov 2012 14:28:16 +0100

Mikael,

> b) I never imagined, a) would be nice if that could be solved. I don't see any text in that draft regarding source based routing though.

correct, we haven't described that anywhere I think.

> What happens if the host doesn't support 5.5?

one of the other things in my list happens.
ICMP type 1,code 5
ICMP redirect
blackhole
.
.

> So, I still can't find anything about a mechanism for routers in homenet for network-wide discovery of where a certain src address packet should be sent when it's destined for the default route (to the Internet).
> 
> Why can't OSPF be used (needs new functionality) so that all homenet routers learn a default-route per prefix, and thus have multiple default routes, and select which one to use depending on what the src address is of the packet? That would relieve the hosts of having to do anything at all (it is nice if they can do 5.5, but things wouldn't break without it). Basically "multi-topology" but instead of being one for IPv4 and one for IPv6, we now have one topology per ISP allocated prefix.
> 

no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF.
the hosts would still do better if they support rule 5.5 when directly connected to the exits.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Nov 2012 16:15:42 +0100 (CET)

On Thu, 15 Nov 2012, Ole Trøan wrote:

> no, this is pretty much what we imagined, and what Markus has 
> implemented and showed at the IETF. the hosts would still do better if 
> they support rule 5.5 when directly connected to the exits.

Absolutely, 5.5 is a plus and gives one less hop in the path, but at least 
the packet will be ultimately delivered to its final destination.

So with the above "pretty much what we have imagined", is there consensus 
that this is the way to go, or this is still being debated?

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 16:56:02 +0100

Op 15 nov. 2012, om 16:15 heeft Mikael Abrahamsson het volgende geschreven:

>> no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF. the hosts would still do better if they support rule 5.5 when directly connected to the exits.
> 
> Absolutely, 5.5 is a plus and gives one less hop in the path, but at least the packet will be ultimately delivered to its final destination.
> 
> So with the above "pretty much what we have imagined", is there consensus that this is the way to go, or this is still being debated?

Step 5.5 is half a solution.

Smarter hosts would make usage of more information, e.g. prefer a better path. BRDP makes such information available (again, no code yet). This is the superseded rule 8: when host knows better, it makes more sensible decisions. RFC 6724 page 13:

                                     For example, if the implementation
   somehow knows which source address will result in the "best"
   communications performance.

Remark on ICMP Redirect: when router forwards a packet back to a better first-hop, based on routing on source address, it MUST NOT send a redirect. If it would, it could influence first-hop for other source prefixes. That gets messy. 

Teco

> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> homenet mailing list
> [email-masked]

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Thu, 15 Nov 2012 16:26:03 +0000

Mikael,

Given that we want multiprefix multihoming with multiple prefixes, SADR is pretty much the only solution. 

But consesus? Wouldn't dear getting anywhere close to that. :-)

Cheers,
Ole

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 15 Nov 2012 16:44:55 +0100

> MAY in section 7, which doesn't make this predictable.
It's exactly that section. The MAY obviously leaves a lot of room there. 
About DHCPv6 I don't know as I haven't tried that. Good question.
> The two might be of equal standing and both offer a route to ::/0.
Well, actually true.. So, yes you're right, source based routing in the 
host should become a MUST.
> I don't believe that is fully specified either. Each new socket
Different apps might use different addresses, the same app probably not. 
They would reuse the same socket options all the time I believe. Anyhow, 
this is just what I've observed so far. It's not how it probably 
should/could be.
> Then why is MIF still arguing?
Because this behaviour is not ideal. It's what I've observed, and 
probably the result of an unfinished implementation due to lack of 
specification. Somebody had to fix things somehow.
> Sure, but we are worried here about zero-conf defaults.
Yes. Source based routing a MUST. I agree.
> Not good enough - it needs to be specified.
I agree. That might be something to add to RFC 3484. Unless  it's 
already in there, but I couldn't find it.
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/
Ah, something new to read.
Thanks,

Mat

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Nov 2012 17:27:46 +0000

Chiming in as a consumer... [the views represented are 100% my own, individual, consumer perspective]
I'm a consumer of wireless service. I hear people engaged in wireless networks saying things like "Prefix delegation isn't till 3GPP release 10; the best a device can do till then is assume that they have the prefix advertised by the RA" and "wireless connections will use a single stack -- either IPv4 or IPv6 but not both". I sure wish I could use wireless as a backup for my home network if I lose my wireline connections. Of course, with the devices I have (my smart phone for everyday use; I'm too cheap to go out and get an additional wireless service or specialized data-only device), I'd need to use "tethering" which is limited to something like 3 devices, that all have to use Wi-Fi. I have more than 3 devices, and not all Wi-Fi, so what I'd probably do is use this Wi-Fi/Ethernet bridge I have lying around the house (I've used it at various times to provide Wi-Fi connectivity to devices that don't support Wi-Fi), and plug the Ethernet side of that into the WAN port of a router. That router looks like a single device from a tethering perspective, and I can do whatever I want behind it, without, um, permission from anyone else. But when (single stack) IPv6 gets offered on that tether, that router will only have a single /128 address. Hmm.

I'm also a consumer of 2 wireline broadband connections. Each has its own router. The routers are totally mine. Neither router is supplied by the associated provider (routers aren't even an option from either provider). They have no connection to each other (because I buy cheap off-the-shelf consumer stuff, and cheap consumer stuff does nothing for multihoming today). Both broadband connections currently support 6rd. From one, I end up with a /64. From the other I end up with a /60.

I've dedicated one of my wireline services to me (the low bandwidth one with the /60), and the other one (the high bandwidth with a /64) is for me and everyone else in my family and the rest of my home network. The printer is connected to the 2nd, so I have to switch my Wi-Fi connection to the other when I want to print. How annoying. I have, in the past, put other routers behind the general home network connection (the one from the /64 provider), like when I needed a Wi-Fi WEP connection for an ancient TiVo, and, well, for other reasons. I have various cheap routers lying around the house, so I prefer to just use them when the need strikes, rather than go and get a new box that can do it all. With IPv6, I will need new routers, but I'll be going cheap on them, too. None of the apps behind the 2nd router are sensitive to dual NAT, so there's no need to do anything other than put them on separate subnets. All cheap routers support that, and it's pretty easy. Much easier than making them bridged APs (which has often caused mysterious DNS and disappearing IPv4 connectivity issues that I never bothered figuring out since dual NAT worked just fine).

My reasons for having 2 connections aren't all that geeky. My family's Netflix and MMORPG gaming addictions were impacting my ability to work at home, by using up all the bandwidth. As my family's home networking "guru", knew I had choices of doing QoS (which would make me happy but not them, and require a more expensive router that could do QoS -- I know this because I've seen those boxes at Fry's that say they do QoS), having a single connection with more bandwidth, or adding a 2nd connection with more bandwidth. I chose to get a 2nd connection, because it wasn't that costly and provided me with redundancy, in this era of Internet connectivity as a need rather than a want. I know I'm not alone in subscribing to multiple broadband services -- several of my neighbors also work at home (or run businesses from their home) and have redundancy. 

I don't know how long the lack of wireless PD delegation will exist, or how long my wireline IPv6 will be offered via 6rd.
All I know is, this is my world as it currently exists.
Y'all know that "Serenity Prayer" about accepting that which you cannot change, having the courage to change what you can, and the wisdom to know the difference? Well, I accept that I can't change those access networks. I get what they give me, and I don't hold my breath waiting for them to change. But I *can* change the devices in my home network. As long as I don't have to pay a lot to do so. 

Anyway, I'd really like it if I could get ISP-provided IPv6 working behind that router that I describe on the wireless connection (the one that will get a single-stack /128 address behind the tethering device -- and I think I'd rather do IPv6 to IPv6 Internet endpoints, even if it is NAT66 on the router, rather than go through NAT64 somewhere; and I really don't want to do "NAT464" to get to IPv4 endpoints behind a single-stack IPv6 connection). I'd also like to do IPv6 to IPv6 endpoints from behind a 2nd router behind my general-purpose home network router (the one that gets a /64 from 6rd). Right now, I can't, AFAIK. Since I have all of these connections, it would be nice if I didn't have to physically move between them, but could have them connected together and just configure a few simple choices to make things work (the way *I* want them to work -- so I do expect some simple configuration). 

Getting my multihoming working is more of a "nice to have" right now, though, since I've got to keep IPv4 working right, and I don't see anything being done to solve IPv4 multihoming. I thinks that's something that I won't bother trying to change. The cascaded router scenario (in the tethered single-stack wireless network and in my general purpose home network) works today with IPv4. But not with IPv6. That's a problem. The /64 is very real in both of those cases, and breath-holding or crying about it just doesn't seem to be a very effective approach. 

That's my consumer wish list. Thanks for listening. Maybe I'll put this in my letter to Santa.
Barbara

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Turner
> Sent: Wednesday, November 14, 2012 1:58 PM
> To: [email-masked]
> Subject: Re: [homenet] prefix assignment on home networks
> 
> 
> I'm not against one or more  /64 bit prefixes for a home net, if everyone else
> (including the ISPs) think that home networks should be able to scale up to
> 18,446,744,073,709,551,615 hosts, I'm completely on board.  It's not my
> resource, so I'll take all they give me.  :)  It would be nice to have an AT&T,
> Verizon, or some other major provider chime in to say they're on board with
> the assumptions we're making.  Maybe they already have, I've been away
> from the list for awhile, or maybe they've indicated this allocation strategy in
> some other forum.  I'm old school and I'm not used to having publicly
> routable address space to burn.
> 
> Randy
> 
> > I have a /48 at home, on a retail ISP, right now.  I know, one data point does
> not a trend make, but it is a proof by example that some ISP is doing that.
> >
> > Andrew
> >
> because that's the way a particular protocol works (SLAAC).   Maybe we need
> another method. One /64 for a home network seems like overkill regarding
> address space utilization -- A /32 would be overkill.  I know some folks think
> we have more address space than we'll ever use, but gee....
> >>
> >> Randy
> >>
> >>
> >>>>> I was thinking that, in an effort to reduce scope to something we can
> deal with for now, that a /64 would be big enough
> >>>>
> >>> I don't see the point in working on the /64 case-if that's all we're trying
> to accomplish, we've already accomplished it.   The interesting work
> Homenet is doing is in fact trying to solve the prefix distribution and
> automatic setup problem.   It's true that this is a hard problem.   It's also true
> that if we don't specify a solution, people will attempt to solve it in their own
> ways.   And if they do that, we will wind up in the situation that Jim found
> himself in with his broken box with its own built-in DHCP server.
> >>>
> >>> BTW, a little more on that topic: the reason that two DHCP servers on
> the same wire broke Jim's network in a flaky way is that IPv4 doesn't handle
> the multi-homing case.   IPv6 deliberately places the multi-homing case in-
> scope.   This creates a bit of a problem for legacy apps that do not support
> multi-homing, but it also creates the winning situation that if one device is
> advertising a provisioning domain that doesn't work, applications that do
> correctly handle multi-homing will simply use a different provisioning
> domain.
> >>>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 15 Nov 2012 09:36:44 -0800

On 11/15/12 9:27 AM, STARK, BARBARA H wrote:
> I'm a consumer of wireless service. I hear people engaged in wireless networks saying things like "Prefix delegation isn't till 3GPP release 10; the best a device can do till then is assume that they have the prefix advertised by the RA" and "wireless connections will use a single stack -- either IPv4 or IPv6 but not both". I sure wish I could use wireless as a backup for my home network if I lose my wireline connections. Of course, with the devices I have (my smart phone for everyday use; I'm too cheap to go out and get an additional wireless service or specialized data-only device), I'd need to use "tethering" which is limited to something like 3 devices, that all have to use Wi-Fi. I have more than 3 devices, and not all Wi-Fi, so what I'd probably do is use this Wi-Fi/Ethernet bridge I have lying around the house (I've used it at various times to provide Wi-Fi connectivity to devices that don't support Wi-Fi), and plug the Ethernet side of that into the WAN port of a rout
>   er. That router looks like a single device from a tethering perspective, and I can do whatever I want behind it, without, um, permission from anyone else. But when (single stack) IPv6 gets offered on that tether, that router will only have a single /128 address. Hmm.
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.
> I've dedicated one of my wireline services to me (the low bandwidth one with the /60), and the other one (the high bandwidth with a /64) is for me and everyone else in my family and the rest of my home network. The printer is connected to the 2nd, so I have to switch my Wi-Fi connection to the other when I want to print. How annoying. I have, in the past, put other routers behind the general home network connection (the one from the /64 provider), like when I needed a Wi-Fi WEP connection for an ancient TiVo, and, well, for other reasons. I have various cheap routers lying around the house, so I prefer to just use them when the need strikes, rather than go and get a new box that can do it all. With IPv6, I will need new routers, but I'll be going cheap on them, too. None of the apps behind the 2nd router are sensitive to dual NAT, so there's no need to do anything other than put them on separate subnets. All cheap routers support that, and it's pretty easy. Much easier than m
>   aking them bridged APs (which has often caused mysterious DNS and disappearing IPv4 connectivity issues that I never bothered figuring out since dual NAT worked just fine).
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2012 12:41:09 -0500

On Nov 15, 2012, at 12:27 PM, "STARK, BARBARA H" <[email-masked]> wrote:
> The cascaded router scenario (in the tethered single-stack wireless network and in my general purpose home network) works today with IPv4. But not with IPv6. That's a problem. The /64 is very real in both of those cases, and breath-holding or crying about it just doesn't seem to be a very effective approach. 

Thanks for the long expression of your use case—I think it's a useful example.

I do want to take exception to one thing here, though: cascaded routers do not work with IPv4.   They work with IPv4+NAT, or with IPv4+bridge.   And "work" is relative, as your use case story shows.

Chances are that part of the reason you had to go to a multi-homed connection was that your router configuration was suffering from bufferbloat, and so despite you having a decent connection to your ISP, you were experiencing congestion.   This is, unfortunately, very typical of home routers nowadays.

Adding a second entire network for your own private use worked, but it was probably overkill.   If you are feeling adventurous, you might want to try setting up a CeroWRT network with properly tuned buffers and see if it changes things for you.   I can't promise that it does—I'm just a happy user of CeroWRT, not an expert on bufferbloat.   But the network behavior you are describing sounds a lot like what I was trying to cure when I installed CeroWRT.

What does this have to do with the homenet discussion?   We should be proposing a solution that doesn't perpetuate the architecture that leads to bufferbloat.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Nov 2012 18:14:46 +0000

> Chances are that part of the reason you had to go to a multi-homed
> connection was that your router configuration was suffering from
> bufferbloat, and so despite you having a decent connection to your ISP, you
> were experiencing congestion.   This is, unfortunately, very typical of home
> routers nowadays.

No, my connection to my first ISP is 1.5Mbps downstream. The 2nd connection is 30Mbps downstream. A single Netflix stream had no difficulty taking up the entire 1.5Mbps. Unfortunately, the technology used to offer the 1.5Mbps service could only be upgraded to a maximum of 3Mbps. I figured Netflix could probably overrun that too, so I went with the 2nd connection. I could have just switched everything to the 2nd connection (my routers haven't had any difficulty with doing everything asked of them on the 30 Mbps connection -- Netflix users are very happy and the shrieks from the MMORPG addict mourning death due to lousy Internet connectivity have stopped), but I like the redundancy of having 2, and the 1.5 Mbps service is very inexpensive.

> Adding a second entire network for your own private use worked, but it was
> probably overkill.   

Not overkill. Just redundant. But I and my family need our Internet. We cannot live without it. Redundancy is good when it isn't expensive.

> If you are feeling adventurous, you might want to try
> setting up a CeroWRT network with properly tuned buffers and see if it
> changes things for you.   I can't promise that it does-I'm just a happy user of
> CeroWRT, not an expert on bufferbloat.   But the network behavior you are
> describing sounds a lot like what I was trying to cure when I installed
> CeroWRT.

Hmm. I'm busy with other adventures right now, and not feeling the need. I'll keep it in mind, though.
 
> What does this have to do with the homenet discussion?   We should be
> proposing a solution that doesn't perpetuate the architecture that leads to
> bufferbloat.

/64s are very real, and the need to accommodate them appears to be relatively near-term. Multi-homing is real. Improved multi-homing experience is desirable, but not an immediate need.
A diagnosis of bufferbloat sounds difficult to cure (requiring adventures and acronyms), so I think I'll stick with my state of denial regarding that.
Barbara

---

From: Jim Gettys <[email-masked]>
Date: Thu, 15 Nov 2012 13:35:06 -0500

We're testing fq_codel on DSL right now on a particular Lantiq home router
with OpenWrt and CeroWrt (Broadcom, the most common chip vendor for DSL
devices, has not been cooperative with Linux/Open source,

It makes a dramatic difference in bufferbloat and perceived performance
(and on DSL, won't require messing with QOS settings, as we don't have to
put in an artificial bottleneck requiring tuning).

Results (on .5Mbps uplinks) should end up similar to those reported here
(though Michael misidentified exactly why what he's doing works on his
hardware):

http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat

In a few weeks, I'll announce which router and how to get the bits for the
adventurous, and willing to spend less than $100 for a new home router to
run in on.
                                 - Jim

On Thu, Nov 15, 2012 at 1:14 PM, STARK, BARBARA H <[email-masked]> wrote:

> No, my connection to my first ISP is 1.5Mbps downstream. The 2nd
> connection is 30Mbps downstream. A single Netflix stream had no difficulty
> taking up the entire 1.5Mbps. Unfortunately, the technology used to offer
> the 1.5Mbps service could only be upgraded to a maximum of 3Mbps. I figured
> Netflix could probably overrun that too, so I went with the 2nd connection.
> I could have just switched everything to the 2nd connection (my routers
> haven't had any difficulty with doing everything asked of them on the 30
> Mbps connection -- Netflix users are very happy and the shrieks from the
> MMORPG addict mourning death due to lousy Internet connectivity have
> stopped), but I like the redundancy of having 2, and the 1.5 Mbps service
> is very inexpensive.
>
> Not overkill. Just redundant. But I and my family need our Internet. We
> cannot live without it. Redundancy is good when it isn't expensive.
>
> /64s are very real, and the need to accommodate them appears to be
> relatively near-term. Multi-homing is real. Improved multi-homing
> experience is desirable, but not an immediate need.
> A diagnosis of bufferbloat sounds difficult to cure (requiring adventures
> and acronyms), so I think I'll stick with my state of denial regarding that.
> Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Nov 2012 18:41:56 +0000

> > But when (single stack) IPv6 gets offered on that tether, that router will
> > only have a single /128 address. Hmm.

 > http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.

Which, I suspect, is how the router would get that single /128 address. That works nice for the 3GPP tethering device to know it has a /64 that it can offer for SLAAC use to tethered (non-3GPP) devices to self-assign a /128. It's not so useful for my tethered (non-3GPP) off-the-shelf home networking router connected out its WAN port to the tethering device through an Ethernet/Wi-Fi bridge, to provide addresses to the home network on its LAN.

Not all of the devices on my home network do Wi-Fi. And even if they did, homing them all to point to the tethering device (many of which only support 3 or so tethered devices) would require effort. It's much easier for me to configure a single Ethernet/Wi-Fi bridge to point to the tethering device, and plug that into the WAN port of a regular home router. I know how to do this (in the IPv4 world). I could even describe to my mother-in-law how to do this.
Barbara

---

From: joel jaeggli <[email-masked]>
Date: Thu, 15 Nov 2012 11:52:05 -0800

> Which, I suspect, is how the router would get that single /128 address. That works nice for the 3GPP tethering device to know it has a /64 that it can offer for SLAAC use to tethered (non-3GPP) dev…
There are somewhat limited options in my understanding with 3gpp release 
7 networks, this sounds like a relatively good idea given the 
limitations but it's use generally seems like kind of a bad idea. That 
said I'm in favor of bad options over no options, and I think it's 
heartening to see operators try and make this work.
> Not all of the devices on my home network do Wi-Fi.
really only one of them has to in the case of a bridge,
>   And even if they did, homing them all to point to the tethering device (many of which only support 3 or so tethered devices) would require effort.
The limit on the supported number of tethered devices is somewhat 
arbitrary, a usb dongle in business style cpe doesn't have the same 
limitations that my mifi does
>   It's much easier for me to configure a single Ethernet/Wi-Fi bridge to point to the tethering device, and plug that into the WAN port of a regular home router. I know how to do this (in the IPv4 world). I could even describe to my mother-in-law how to do this.
I would agree that if it's not easy  it's likely not going to workable 
general case. mobile phones that provide the bulk of the tethering 
capability already bind to the homenet (as clients/hosts) so they've 
already built the association necessary to offer service.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Nov 2012 20:06:52 +0000

> 7 networks, this sounds like a relatively good idea given the limitations but it's
> use generally seems like kind of a bad idea. That said I'm in favor of bad
> options over no options, and I think it's heartening to see operators try and
> make this work.

Um, I really tried to indicate that my views were mine and were intended to reflect my thoughts as a consumer. Not an operator. So please don't feel quite so heartened.
Barbara

---

From: joel jaeggli <[email-masked]>
Date: Thu, 15 Nov 2012 12:39:58 -0800

>> options over no options, and I think it's heartening to see operators try and
Sorry the operator in this  context was Cameron/t-mobile in specific, 
operators who commented on this method, in general.
>> Um, I really tried to indicate that my views were mine and were intended to reflect my thoughts as a consumer. Not an operator. So please don't feel quite so heartened.
yeah I understood your position.

---

From: james woodyatt <[email-masked]>
Date: Thu, 15 Nov 2012 13:04:13 -0800

On Nov 15, 2012, at 04:26 , Ted Lemon <[email-masked]> wrote:
> Those hosts are broken.   They can't work in a multi-homed environment.

Those hosts are not broken.  They work fine in single-homed edge networks, which are ubiquitous.  The deployment of multiple heterogenous default routers with hosts that expect networks to be single-homed is what breaks the network.

Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should automatically go to the next available default router, but existing flows will still be broken in the absence of the kind of coordination I described previously.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Nov 2012 16:20:19 -0500

> Those hosts are not broken.  They work fine in single-homed edge networks, which are ubiquitous.  The deployment of multiple heterogenous default routers with hosts that expect networks to be singl…

It breaks the network because hosts in this environment cannot be counted on to do the obviously right thing, but instead are encouraged by the standard to behave in ways that can be counted on to be wrong almost all the time.

It's true that they are not broken with respect to the standard, but what the standard encourages them to do is the very essence of what it means to be broken.   We should fix it, not wring our hands and point out reasons why it's not our fault that the standard and the hosts that follow it are broken.

---

From: james woodyatt <[email-masked]>
Date: Thu, 15 Nov 2012 13:21:09 -0800

> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should aut…

Well, this is just wrong.  I didn't think this through completely.  Rule 5.5 of RFC 6724 *is* inadequate, but not for precisely the reason I describe above.  It would help, but Rule 3 overrides it, and dragons await the unwary sailor who doesn't keep synchronized clocks.

---

From: Ole Trøan <[email-masked]>
Date: Fri, 16 Nov 2012 10:28:42 +0100

James,

> Those hosts are not broken.  They work fine in single-homed edge networks, which are ubiquitous.  The deployment of multiple heterogenous default routers with hosts that expect networks to be singl…

given dual stack. all hosts are multi-homed.
multiple prefixes and multiple default routers have been part of the IPv6 design from day 1.

> Also, rule 5.5 of RFC 6724 is inadequate.  Hosts that implement it should work better than those that don't because new flows created after the primary default router becomes unreachable should aut…

arguing from a standards perspective (not what implementations do). I don't think any of our documents describe a "primary default router". 

given we have: RFC4861, RFC4311, RFC4191 and RFC6724 what is missing?
combined with happy eyeballs of course.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Fri, 16 Nov 2012 10:29:16 +0100

> Well, this is just wrong.  I didn't think this through completely.  Rule 5.5 of RFC 6724 *is* inadequate, but not for precisely the reason I describe above.  It would help, but Rule 3 overrides it,…

rule 3 deprecated addresses. how does that apply?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2012 09:50:17 +0000

Ole,

> combined with happy eyeballs of course.

I think a unified explanation of the best current practice is
missing. Also there is that MAY in 6724 that I mentioned
earlier, which seems weak in view of the discussion here.

   Brian

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 15 Nov 2012 14:05:55 -0800

> switch ISPs to one that isn't so restrictive.

If they can request more than one /64 from the upstream, then can have 
multiple LANs.  However, as far as I can tell from the specs it would 
have to use different IAIDs for each request as getting multiple 
prefixes back in the same IAID means "all these prefixes refer to one 
network."

FWIW, Comcast's currently deployed network will give a /64 to an 
unqualified PD request.  I have been told it will give up to a /60 if 
given an explicit request for a narrowed prefix; I have not been able to 
test it myself at this point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 17:47:45 +0900

On Thu, Nov 8, 2012 at 12:51 AM, Ralph Droms <[email-masked]> wrote:

> Using PD in a home network isn't hard.  Use a single delegating router;
> most obvious choice is the device that received the prefix from the
> external source.
>

That doesn't work in a multihomed situation, though, right? Only if there
is only one border router?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 18:24:09 +0900

Most major wireline deployments provide /60, /56 or /48. Examples: free.fr,
KDDI, AT&T. Exceptions are RCS+RDS (working on shorter prefixes) and some
North American cable operators, which AIUI are crippled by sucky CPEs that
fail to do anything useful when they receive more than a /64.

On Thu, Nov 15, 2012 at 2:27 AM, Randy Turner <[email-masked]>wrote:

>
> Have their been any ISPs that have come forward to discuss their consumer
> IPv6 allocation plans?  I don't think we should wrap ourselves around a
> model that says, "yeah, we need multiple /64s for consumers because that's
> the way a particular protocol works (SLAAC).   Maybe we need another
> method. One /64 for a home network seems like overkill regarding address
> space utilization -- A /32 would be overkill.  I know some folks think we
> have more address space than we'll ever use, but gee….
>
> Randy
>
>
> > I don't see the point in working on the /64 case—if that's all we're
> trying to accomplish, we've already accomplished it.   The interesting work
> automatic setup problem.   It's true that this is a hard problem.   It's
> also true that if we don't specify a solution, people will attempt to solve
> it in their own ways.   And if they do that, we will wind up in the
> situation that Jim found himself in with his broken box with its own
> built-in DHCP server.
> >
> the same wire broke Jim's network in a flaky way is that IPv4 doesn't
> handle the multi-homing case.   IPv6 deliberately places the multi-homing
> case in-scope.   This creates a bit of a problem for legacy apps that do
> not support multi-homing, but it also creates the winning situation that if
> one device is advertising a provisioning domain that doesn't work,
> applications that do correctly handle multi-homing will simply use a
> different provisioning domain.
> >

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2012 08:47:54 -0500

On Nov 19, 2012, at 3:47 AM, Lorenzo Colitti <[email-masked]> wrote:
> That doesn't work in a multihomed situation, though, right? Only if there is only one border router?

If there are two border routers, both advertise their prefixes.   Hosts don't handle this particularly well, as we've discussed elsewhere, but it works just fine in terms of delivering service to the local network.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 21:33:12 -0800

On Mon, Nov 19, 2012 at 5:47 AM, Ted Lemon <[email-masked]> wrote:

> If there are two border routers, both advertise their prefixes.   Hosts
> don't handle this particularly well, as we've discussed elsewhere, but it
> works just fine in terms of delivering service to the local network.
>

It's not just that. For example, if one of the border routers is unplugged,
the hosts stay configured with invalid addresses until the lease expires.