Re: [homenet] prefix assignment on home networks

[Lorenzo Colitti]

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 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
>
>
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>
> > On Nov 14, 2012, at 3:31 AM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> >> 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.
> >
> > 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.
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> >
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Brian E Carpenter]

Ole,

On 16/11/2012 09:28, Ole Trøan wrote:
> James,
> 
 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.
>> 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.
> 
> 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 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.
> 
> 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.

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

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

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

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

rule 3 deprecated addresses. how does that apply?

cheers,
Ole

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

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

James,

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

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

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


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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 15, 2012, at 13:04 , james woodyatt  wrote:
> 
> 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.

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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 15, 2012, at 4:04 PM, james woodyatt  wrote:
> 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.

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.

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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 15, 2012, at 04:26 , Ted Lemon  wrote:
> On Nov 14, 2012, at 10:41 PM, james woodyatt  wrote:
>> 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.

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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[joel jaeggli]

On 11/15/12 12:06 PM, STARK, BARBARA H wrote:

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

Barbara



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

Re: [homenet] prefix assignment on home networks

[STARK, BARBARA H]

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[joel jaeggli]

On 11/15/12 10:41 AM, STARK, BARBARA H wrote:

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

Barbara




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

Re: [homenet] prefix assignment on home networks

[STARK, BARBARA H]

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

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

Re: [homenet] prefix assignment on home networks

[Jim Gettys]

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  wrote:

> > 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
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[STARK, BARBARA H]

> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 15, 2012, at 12:27 PM, "STARK, BARBARA H"  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.

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

Re: [homenet] prefix assignment on home networks

[joel jaeggli]

d 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


-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
Behalf Of Randy Turner
Sent: Wednesday, November 14, 2012 1:58 PM
To: homenet@ietf.org
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

On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:


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

On 15/11/2012, at 6:27 AM, 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

Randy


On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:


On Nov 14, 2012, at 3:31 AM, Brian E Carpenter

 wrote:

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.

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.

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


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



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

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




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

Re: [homenet] prefix assignment on home networks

[STARK, BARBARA H]

uter, 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

> -Original Message-
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
> Behalf Of Randy Turner
> Sent: Wednesday, November 14, 2012 1:58 PM
> To: homenet@ietf.org
> 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
> 
> On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:
> 
> > 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
> >
> > On 15/11/2012, at 6:27 AM, 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
> >>
> >> Randy
> >>
> >>
> >> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
> >>
> >>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter
>  wrote:
> >>>> 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.
> >>>
> >>> 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 winni

Re: [homenet] prefix assignment on home networks

[Mattia Rossi]

Am 15.11.2012 13:09, schrieb Brian E Carpenter:

On 15/11/2012 10:19, Mattia Rossi wrote:

On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:


On 14/11/2012 22:44, james woodyatt wrote:

On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  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.

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


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.

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



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.
Well, actually true.. So, yes you're right, source based routing in the 
host should become a MUST.



The
host/applications will also only use one prefix at a time, thus always send
the packets down the correct path.

I don't believe that is fully specified either. Each new socket
might make a new choice.
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.



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.

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.



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.

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

Yes. Source based routing a MUST. I agree.



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.

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.



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.

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/


Ah, something new to read.
Thanks,

Mat
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ole Troan (otroan)]

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

On 15 Nov 2012, at 16:15, "Mikael Abrahamsson"  wrote:

> On Thu, 15 Nov 2012, Ole Trøan wrote:
> 
>>> Or am I missing things again?
>> 
>> 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?
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Teco Boot]

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

> On Thu, 15 Nov 2012, Ole Trøan wrote:
> 
>>> Or am I missing things again?
>> 
>> 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 Abrahamssonemail: 
> swm...@swm.pp.se___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

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


Or am I missing things again?


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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

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

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


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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

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.


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.


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.



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


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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

Mikael,

>> 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?
> 
> 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 
>  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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

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


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?


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


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

Mikael,

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

On Thu, 15 Nov 2012, Ted Lemon wrote:


On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson  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 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?

--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 15, 2012, at 6:20 AM, Mikael Abrahamsson  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?

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

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 14, 2012, at 10:41 PM, james woodyatt  wrote:
> 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.

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

Re: [homenet] prefix assignment on home networks

[Brian E Carpenter]

On 15/11/2012 10:19, Mattia Rossi wrote:
> On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> On 14/11/2012 22:44, james woodyatt wrote:
>>> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  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.
>>
>> Of course. I suggested this when MIF started out, and it's a MIF
>> issue still.
>>
> 
> 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.

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
> host/applications will also only use one prefix at a time, thus always send
> the packets down the correct path.

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

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

Then why is MIF still arguing?

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

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

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

Not good enough - it needs to be specified.

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

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

> Mat
> 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

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


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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Ole Trøan]

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Mattia Rossi]

On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 14/11/2012 22:44, james woodyatt wrote:
> > On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  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.
>
> Of course. I suggested this when MIF started out, and it's a MIF
> issue still.
>

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Brian E Carpenter]

On 14/11/2012 22:44, james woodyatt wrote:
> On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  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. 

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

   Brian
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Teco Boot]

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


Op 15 nov. 2012, om 04:41 heeft james woodyatt het volgende geschreven:

> On Nov 14, 2012, at 19:00 , Ted Lemon  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.
> 
> 
> --
> james woodyatt 
> core os networking
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 14, 2012, at 19:00 , Ted Lemon  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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 14, 2012, at 4:44 PM, 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. Right now the only mechanism that comes close to 
> doing that is ICMPv6 Redirect, which isn't suitable for addressing this 
> problem.

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?

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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 14, 2012, at 17:22 , Michael Richardson  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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 14, 2012, at 13:34 , Mikael Abrahamsson  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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

On Wed, 14 Nov 2012, james woodyatt wrote:

Maybe I'm missing something, but I think this is really an intractable 
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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 13, 2012, at 21:30 , joel jaeggli  wrote:
> On 11/13/12 9:20 PM, Mikael Abrahamsson 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?
> 
> If coordination is required, it's not going to work.

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:::/64 to me and BRAVO delegates 2001:db8:::/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:::/64 and 
2001:db8:::/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:::X 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:::/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.


--
james woodyatt 
core os networking

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

Re: [homenet] prefix assignment on home networks

[Randy Turner]

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

On Nov 14, 2012, at 10:40 AM, Andrew McGregor wrote:

> 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
> 
> On 15/11/2012, at 6:27 AM, 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….
>> 
>> Randy
>> 
>> 
>> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
>> 
>>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter 
>>>  wrote:
 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.
>>> 
>>> 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.
>>> 
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>> 
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 

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

Re: [homenet] prefix assignment on home networks

[Andrew McGregor]

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

On 15/11/2012, at 6:27 AM, 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….
> 
> Randy
> 
> 
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
> 
>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter  
>> wrote:
>>> 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.
>> 
>> 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.
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Randy Turner]

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

R.

On Nov 14, 2012, at 9:27 AM, 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….
> 
> Randy
> 
> 
> On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:
> 
>> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter  
>> wrote:
>>> 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.
>> 
>> 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.
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

Re: [homenet] prefix assignment on home networks

[Randy Turner]

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


On Nov 14, 2012, at 7:07 AM, Ted Lemon wrote:

> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter  
> wrote:
>> 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.
> 
> 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.
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

Re: [homenet] prefix assignment on home networks

[Teco Boot]

Op 14 nov. 2012, om 16:58 heeft Michael Thomas het volgende geschreven:

> On 11/14/2012 07:07 AM, Ted Lemon wrote:
>> 
>> 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.
>> 
> 
> 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.

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.

> 
> But the real question I have is: what constitutes a "legacy app"? How
> 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 

> 
> Mike
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment on home networks

[Michael Thomas]

On 11/14/2012 07:07 AM, Ted Lemon wrote:


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.



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Teco Boot]

Op 14 nov. 2012, om 16:07 heeft Ted Lemon het volgende geschreven:

> On Nov 14, 2012, at 3:31 AM, Brian E Carpenter  
> wrote:
>> 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.
> 
> 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.

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

> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment on home networks

[Ted Lemon]

On Nov 14, 2012, at 3:31 AM, Brian E Carpenter  
wrote:
> 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.

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.

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

Re: [homenet] prefix assignment on home networks

[Olafur Gudmundsson]

On 13/11/2012 17:47, james woodyatt wrote:

On Nov 13, 2012, at 10:33 , Randy Turner  wrote:


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 ?


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.



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


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

Re: [homenet] prefix assignment on home networks

[Brian E Carpenter]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[joel jaeggli]

On 11/13/12 9:20 PM, Mikael Abrahamsson 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?


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

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


I hope not.



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

Re: [homenet] prefix assignment on home networks

[Mikael Abrahamsson]

On Tue, 13 Nov 2012, james woodyatt 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.


Then those need to re-think their decisions.

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.


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?


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


I hope not.

--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment on home networks

[Randy Turner]

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


On Nov 13, 2012, at 2:47 PM, james woodyatt  wrote:

> On Nov 13, 2012, at 10:33 , Randy Turner  wrote:
> 
>> 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 ?
> 
> 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 
> core os networking
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

Re: [homenet] prefix assignment on home networks

[Victor Kuarsingh]

On 2012-11-13 5:47 PM, "james woodyatt"  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



>
>
>--
>james woodyatt 
>core os networking
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet


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

Re: [homenet] prefix assignment on home networks

[james woodyatt]

On Nov 13, 2012, at 10:33 , Randy Turner  wrote:

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

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 
core os networking

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

Re: [homenet] prefix assignment on home networks

[Simon Kelley]

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.


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

[homenet] prefix assignment on home networks

[Randy Turner]

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

On Nov 13, 2012, at 10:28 AM, Randy Turner  wrote:

> 
> 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
> 
> On Nov 13, 2012, at 9:22 AM, Mark Townsley  wrote:
> 
>> 
>> On Nov 13, 2012, at 5:27 PM, Dave Taht wrote:
>> 
>>> On Tue, Nov 13, 2012 at 5:01 PM, Michael Thomas  wrote:
 On 11/13/2012 12:24 AM, Brian E Carpenter wrote:
> 
> On 12/11/2012 17:33, Mark Townsley wrote:
>> 
>> 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.
> 
> 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.
> 
 
 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.
>>> 
>>> +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.
>> 
>> 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