Subject: [homenet] homenet requirements on ISPs -- should write them down?

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2015 14:01:48 -0400

This WG has been chartered to address networking issues in the home.
In the process of doing this we have made various assumptions about what ISPs
might (or might not) provide.  These have mostly been aligned with what other
groups (particularly ops area groups) have said.

In many cases, we have taken the approach about what ISPs might/sometimes do,
or things that we think all ISPs will do.  For instance, BCP38 (ingress
filtering of source addresses) puts a significant constraint on how we build
our homenets.  We have also said decided that we won't deal with the case
where an ISP provides enough IPv6 space to number the homenet, (other than to
say that we hope to fail gracefully).

QUESTION:
        I wonder if we should collect these things into an ISP requirements document.
        Well... "requirements" might be too strong a word here.   Maybe "wishlist" is
        more appropriate; my purpose is not to argue the precise term here, but
        rather to condense the list more clearly.

BACKGROUND to why this email today:

I say this with a hat I wear a few days/month as the maintainer of a PPPoE
appliance/access concentrator that has widespread deployment, and has been
shipping IPv6 (rfc6204/7084) support since last fall.
I think that it will grow support for additional things we might specify in
homenet.  For instance delegation of reverse DNS zones.

(In creating my work plan, in the end I had to reverse engineer the Broadband
Forum TR-187 to decide what services I needed to provide. RFC6204 wasn't enough)

I am updating the NTP software in this appliance, and I'm looking at a
question, should I enable 5906 by default.  rfc5906 is, to save you a trip to
your browser:
             Network Time Protocol Version 4: Autokey Specification
   This memo describes the Autokey security model for authenticating
   servers to clients using the Network Time Protocol (NTP) and public
   key cryptography.  Its design is based on the premise that IPsec
   schemes cannot be adopted intact, since that would preclude
   stateless servers and severely compromise timekeeping accuracy.  In addition,
   Public Key Infrastructure (PKI) schemes presume authenticated
   time values are always available to enforce certificate lifetimes;
   however, cryptographically verified timestamps require interaction
   between the timekeeping and authentication functions.

...
In smaller, understaffed ISPs, anything the edge concentrator can do out
of the box without additional configuration is a boon, so being the NTP
server for the connected homes is a good thing.... should I think about
turning on 5906?  well, the question becomes: will anyone need it?

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Apr 2015 10:02:11 +0100

Hi,

> On 27 Apr 2015, at 19:01, Michael Richardson <[email-masked]> wrote:
> 
> 

I agree.

I think there are a number of things that could/should be teased out of the work done
to date and made more explicit (and expanded) in separate documents. These might
include, as rough working titles :

- Recommendations for ISPs providing residential IPv6
- Management and monitoring of IPv6 home networks (something Joel asked for as we
  wrapped up RFC7368)
- Security architecture for IPv6 home networks
- Graceful(!) renumbering of IPv6 home networks (drawing on 6renum and its gaps document)

The ISP document would also help more knowledgable customers understand the
expectations they might have of their ISP.

Something for the chairs to consider. None of the above should prevent existing work
continuing, but it may be useful to document common understanding of what we’re
trying to achieve.

Tim

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

---

From: Ray Bellis <[email-masked]>
Date: Tue, 28 Apr 2015 10:18:32 -0700

On 28/04/2015 02:02, Tim Chown wrote:

> Something for the chairs to consider. None of the above should
> prevent existing work continuing, but it may be useful to document
> common understanding of what we’re trying to achieve.

It sounds like a fine idea to me, but I shall need to discuss with my
co-chair and AD when I get back to the UK next week, not least to
confirm whether it's in charter (and if not, whether the charter could
be updated to accommodate this).

Ray