Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

>> Both HNCP and Babel carry their control traffic over link-local IPv6, but
>> they support both IPv4 and IPv6 with almost equal functionality.
>> 
>> (The only significant difference is the treatment of border routers, which
>> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

> Oh, I thought the charter was for v6 only.  Did that change, or am
> I misremembering?

Yeah, I never understood that.  The charter is pretty much v6-only, but
I don't recall anyone ever suggesting that we should omit IPv4 support
(but then, I only got involved around the summer of 2014).  RFC 7788 says:

   While RFC 7368 sets no requirements for IPv4 support, HNCP aims to
   support the dual-stack mode of operation, and therefore the
   functionality is designed with that in mind.

while the Babel profile for Homenet says:

   REQ3: a Homenet implementation of Babel SHOULD implement the IPv4
   subset of the protocol

The implementation status is pretty solid:

  - both implementations of HNCP (hnetd and shncpd) have good support for
IPv4 and DHCPv4;
  - of the six implementations of Babel known to me, four support IPv4
(babeld, BIRD, FRR and David's Top Secret Implementation).

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 8:50 PM, Juliusz Chroboczek  wrote:
> That's an property of the hnetd implementation, not a feature of the
> protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

The text:

  An HNCP router MUST create a private IPv4 prefix [RFC1918 
]
  whenever it wishes to provide IPv4 Internet connectivity to the
  network and no other private IPv4 prefix with Internet
  connectivity currently exists.  It MAY also enable local IPv4
  connectivity by creating a private IPv4 prefix if no IPv4 prefix
  exists but MUST NOT do so otherwise.

So it does allow the implementation to use use RFC1918 addresses internally 
when there is no upstream address, but it really does seem to be saying that’s 
not necessary.   Better advice would be that if an IPv4 address is ever 
obtained externally, that internal RFC1918 addressing should remain available 
until some substantial amount of time has passed.   Right now this behavior is 
optional.

>> This is one of the reasons that I would like us to get together and hack on
>> this at the hackathon:
> 
> It should be an easy fix, feel free to go ahead.

The point of soliciting participation at hackathon is for us to gain collective 
experience on the easy or difficulty of deploying homenet in practice.   It’s 
all very well and good to have implementations, but if nobody is able to use 
them, this isn’t really what we want when we talk about having interoperating 
implementations.   This is particularly true when the goal of a body of work is 
automatic operation (as in ops), as opposed to mere protocol interoperation.

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

> in fact while what you are saying is technically true, in practice IPv4
> _is_ treated like a second-class citizen in the sense that if your
> ISP-provided public IP address ever goes away, all of your RFC1918
> addresses on the homenet also go away.

That's an property of the hnetd implementation, not a feature of the
protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

> This is one of the reasons that I would like us to get together and hack on
> this at the hackathon:

It should be an easy fix, feel free to go ahead.

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

... if your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

 Not in any router I’ve ever had a hand in specifying or procuring! And 
not true of my Netgear router, or any of my older Linksys routers. Or OpenWRT 
loaded routers. My RFC1918 addresses absolutely stay put. I just can’t access 
the Internet (through that broadband connection) when my ISP-provided public IP 
address goes away. I’m not aware of any router that loses its RFC1918 addresses 
when the WAN goes down.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> For the last 10 to 15 years the ISP-provided home router has come to
> dominate the market, with the belief by the ISPs that this is a MUST that they
> control the device.  Many (but not all) at the IETF do not share this view, 
> but
> most non-technical users see the ISP provided router is simply saving the trip
> to
> BestBuy, rather than an abdication of control over their home.   If this
> trend continues, then I believe that ISPs (residential IAPs) will come to want
> to control all IoT devices in the home -- because security -- telling 
> residential
> customers what they can and not connect.

Just to be clear, the main reasons most ISPs require use of the ISP CE router 
at the edge of mass market customer networks is because:
1. Providing instructions for installation and setup becomes easier, as well as 
ensuring the installation process is as trouble-free and easy as possible.
2. Improved but simplified security between the CE router and the access network
3. Cost of help desk support is greatly reduced because help desk personnel 
only have to know how to guide customers through one GUI, and the help desk can 
get permission from the customer (when on a call with the customer) to directly 
manage the router if the customer prefers that approach.

The cost of supporting a customer under a bring-your-own-random-CE-router model 
is considerably higher than the cost of supporting a customer in an 
ISP-managed/specified/provided-CE-router model.

None of which prevents anyone from putting their own router between the ISP CE 
router and their home network. That's what I do. The ISP doesn't control my 
home network and there's no requirement from the ISP that they control my home 
network. I have not abdicated control of my home network to my ISP.

Home automation services may be offered by an ISP, but I'm not aware of any 
case in the US (or Europe) where someone who wants home automation / security 
is required to get it from their ISP or where the ISP has to give permission 
for someone else (or for the homeowner) to operate such a service. I don't know 
the rest of the world.

Can we please avoid making these rather insulting and inflammatory claims 
without evidence? If there's evidence, please provide it. If the evidence 
indicates the practice is localized (to a single ISP, country, or geography), 
please note that when providing evidence. Broad claims that an entire 
IETF-stakeholder group is evil and trying to control everything are not nice.

> I believe that this direction will result in ISPs being 100% liable for 
> attacks on
> critical infrastructure; I don't think that this is a place that ISPs want to 
> be, but
> I'm not sure that they have understood this yet.

I don't know about other ISPs, but I do know my employer takes network security 
very seriously. And access network security (including preventing theft of a 
customer's access service) is one of the reasons I mentioned for providing 
customers with an ISP-provided CE router.

> It's clearly not in
> Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-
> conglomerate's
> interest to be told by ISPs what their products may or may not do.
> This is an ongoing tussle that that relates in some ways (but not all) to the 
> net
> neutrality debate and the desire my ISPs for a cut of the over-top-pie.
> My answer is that the consumer should be in control, and that ISPs need to
> get out of the home router business entirely.  Home router vendors (or the
> service companies they create) should provide first-level support for issues,
> and actual real connectivity issues should be submitted electronically.  Not 
> so
> different in the way that my furnace maintenance is not provided by my gas
> supplier, but my gas supplier gets to inspect the hookup.

No ISP in the US is in a position to tell these companies what they can or 
can't do in a device connected to a customer's network. I can't speak for other 
regions.
There is no evidence that all ISP routers provided by all ISPs in every corner 
of the world prevent all of their customers from being in complete control of 
the home network.  
I remain in complete control of my home network and the devices connected to 
it, independent of the fact that my home network edge router is connected 
through an ISP CE router. Therefore, I know this claim is false in my case.
In any case, I think this comment is well outside the realm of the homenet 
charter.



Barbara

> When we started this effort we heard of real situations such as Fred's 
> original
> FUN BOF slides on how dual-geek households are forced not to share
> printers due to corporate home firewall requirements.  And that we should
> expect the situation to get worse.  Those slides are close to ten years old.
> I'd like to know if they are still at relevant.  Maybe they aren't.
> If not, why not?
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

___

Re: [homenet] homenet: what now? ... next?

[Michael Richardson]

Ralf Weber  wrote:
> Moin!

> On 2 Mar 2019, at 1:14, Michael Richardson wrote:
>> I personally do not believe that Home Router firmware update practices 
have
>> significantly improved.  I would welcome more recent data: is anyone
>> collecting this on a regular basis?  I suspect that 90% of firmware 
updates
>> occur because the (integrated) modem is replaced in order to upgrade
>> bandwidth.

> So you think this is a problem.

I'm saying that the devices are not getting updates, even ISP provided
ones.

>> For the last 10 to 15 years the ISP-provided home router has come to
>> dominate
>> the market, with the belief by the ISPs that this is a MUST that they
>> control
>> the device.  Many (but not all) at the IETF do not share this view, but
>> most
>> non-technical users see the ISP provided router is simply saving the trip
>> to
>> BestBuy, rather than an abdication of control over their home.

> And I agree with most of the non-technical end users there. An ISP 
provided
> router does get updates and in case of problems I can call them and

I do not observe ISP provided modems to get updates.

>> net neutrality debate and the desire my ISPs for a cut of the 
over-top-pie.
>> My answer is that the consumer should be in control, and that ISPs need 
to
>> get out of the home router business entirely.

> I agree that customers should be in control, and they are now as in most
> countries you can choose between an ISP provided routers or buy one at 
your
> convenience. I do not see how less choice (only non ISP provided routers)
> will make this better especially as ISP provided and often managed routers
> are usually updated and taken care of by the ISP in case of problems.

There are quite a number of services in Canada where the ISP provided
modem/router combo has no way to go into a layer-2 only mode.  Or it's very
hard to figure out, or the ISP disdains all notions of supporting you.

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



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Michael Thomas]

On 3/2/19 8:30 AM, Juliusz Chroboczek wrote:

What I meant is that homenet router protocols are v6 only.

No, they're not.

Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.

(The only significant difference is the treatment of border routers, which
are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)


Oh, I thought the charter was for v6 only. Did that change, or am I 
misremembering?


Mike

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 11:30 AM, Juliusz Chroboczek  wrote:
> No, they're not.
> 
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

This is one of the reasons that I would like us to get together and hack on 
this at the hackathon: in fact while what you are saying is technically true, 
in practice IPv4 _is_ treated like a second-class citizen in the sense that if 
your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

So on a practical level, homenets as currently specified really are, if not 
v6-only, then at least only-v6-reliable.

I think it would actually be better if homenets were IPv6-only, with NAT64 at 
the edge for the case where there is only an IPv4 address, but I imagine that 
this would not be a popular enough view to get consensus.  It would be equally 
good if IPv4 were just assumed to be required to work regardless of whether 
there’s an upstream IPv4 address.   This is something that we should really 
re-think—the way it is now isn’t ideal.

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> What I meant is that homenet router protocols are v6 only.

No, they're not.

Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.

(The only significant difference is the treatment of border routers, which
are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Ralf Weber]

Moin!

On 2 Mar 2019, at 1:14, Michael Richardson wrote:
I personally do not believe that Home Router firmware update practices 
have

significantly improved.  I would welcome more recent data: is anyone
collecting this on a regular basis?  I suspect that 90% of firmware 
updates

occur because the (integrated) modem is replaced in order to upgrade
bandwidth.

So you think this is a problem.

For the last 10 to 15 years the ISP-provided home router has come to 
dominate
the market, with the belief by the ISPs that this is a MUST that they 
control
the device.  Many (but not all) at the IETF do not share this view, 
but most
non-technical users see the ISP provided router is simply saving the 
trip to

BestBuy, rather than an abdication of control over their home.
And I agree with most of the non-technical end users there. An ISP 
provided
router does get updates and in case of problems I can call them and they 
will
fix it. I currently experience that myself as my DSL modem (not ISP 
supplied)
is currently experiencing problems, which the ISP provided router does 
not
have. So I now have to research what the actual problem is, which is 
something

most non technical users wouldn’t be even capable of doing.

Also I’ve seen way more intrusion of my home and privacy by over the 
top
providers or IoT devices than I have seen by my ISP. I know this might 
be
different in different parts of the world, which is why we should not 
take

either view for granted.


It's clearly not in
Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-conglomerate's
interest to be told by ISPs what their products may or may not do.
This is an ongoing tussle that that relates in some ways (but not all) 
to the
net neutrality debate and the desire my ISPs for a cut of the 
over-top-pie.
My answer is that the consumer should be in control, and that ISPs 
need to

get out of the home router business entirely.

I agree that customers should be in control, and they are now as in most
countries you can choose between an ISP provided routers or buy one at 
your
convenience. I do not see how less choice (only non ISP provided 
routers)
will make this better especially as ISP provided and often managed 
routers

are usually updated and taken care of by the ISP in case of problems.


Home router vendors (or the
service companies they create) should provide first-level support for 
issues,
and actual real connectivity issues should be submitted 
electronically.
Well I wish I had a pony, but sorry this is not how it works. The 
primary
driver for most people when they buy home routers is price and I doubt 
that

these mostly Asia based companies could support my wider family with a
german speaking hotline. My ISP can though…

On Stephens original question I am between 3 and 4, as I mostly care 
from
an intellectual standpoint, as in man it would be great if that would 
work,
rather then believe we will actually get devices widely deployed, but I 
for

sure would like to play with some in my free time.

So long
-Ralf
—--
Ralf Weber

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