Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt

[Tim Chown <[e-mail]>]

Hi Ray,

Thanks for the thorough review, as always :)

On 20 Oct 2012, at 22:24, Ray Hunter <[e-mail]> wrote:

> Thanks for editing this, Tim.
> 
> As requested, comments towards -06
> 
> Substantive Comments
> ====================
> 
> Section 2.1
> 
> /The addition of routing between subnets raises the issue of how to
> extend mechanisms such as service discovery which currently rely on
> link-local addressing to limit scope. There are two broad choices;
> extend existing protocols to work across the scope of the homenet, or 
> introduce proxies for existing link layer protocols./
> 
> I think there is a viable third choice: Take existing (heavyweight)
> Internet protocols, like DNS and OSPF, that already scale to cover large
> routed infrastructures, and attempt to reduce the amount of expert
> configuration required so that they are suitable for use in networks
> that do not enjoy expert management.

I think the current text supports this, e.g. using OSPF to carry prefix information rather than using DHCPv6 PD.  It also seems that we're leaning heavily towards the naming protocol being DNS-based.

> By the time we've invented proxies and gateways from current mDNS to LLN
> and Internet DNS, we may well end up spending more effort on two-way
> name-space content synchronisation than we'd ever imagine.

The example of service discovery above was just that; there may be other protocols that in current home networks assume a single subnet that may need similar consideration.  I recall we were going to try to list those at some point - I'm not sure we ever did.

Anyway, it's a good point so I have added a bit of text to clarify.

> Section 2.4
> 
> Use of ULA should probably also mention the following challenge:
> 
> Selecting a suitable prefix for use with an address scheme based on ULA
> also presents a challenge when multiple routers are present. The default
> source and destination address selection rules of [RFC6724] only provide
> priority of ULA over GUA within a single /48 ULA prefix. If ULA is to be
> preferred over GUA and multiple routers are present in the home network,
> either the routers will have to co-ordinate selection of a single /48
> ULA prefix for use across the entire home network, or all end nodes and
> routers will have to receive delegated prefixes from each of the union
> all /48 ULA prefixes in use in the home network, or a non-default
> address selection policy will have to be distributed to all end nodes in
> the home network e.g. via [draft-ietf-6man-addr-select-opt-06]

I think there's nothing precluding adding multiple ULA /48's to the policy table as being local.

I have added a note about this to 3.4.2 which talks about stable internal addresses.

> Section 2.6.
> 
> / Ensuring there is a way to access content in the IPv4 Internet. This
> can be arranged through appropriate use of NAT64 [RFC6144] and DNS64
> [RFC6145], for example, or via a node-based DS-Lite [RFC6333] approach./
> 
> Can of worms. Out of scope. Long term there will be no IPv4, or IPv4
> gateway may be outside of Homenet. Suggest deleting the DNS64 text.

I agree this is very tempting, as we say in the intro 'there are no recommendations in this text for the IPv4 part of the network'.  But this is a brief note, to just indicate that there are complications accessing legacy IPv4 content for IPv6-only homenets.

It would be good to get other comment on this.  The text has been kept deliberately as high-level as possible, e.g. not talking about issues with where the DNS64 function is hosted, and we state at the end of 2.6 that the specifics are out of scope of this text.

> Section 3.0
> 
> Is zero config a serious requirement? I just replaced a faulty ADSL2+
> modem/ router. There's loads of config in there for ATM VC's etc. All I
> had to do was go to a web page and select my provider from a drop down
> list. Minimal config and wizard config seems good enough for me and for
> existing products.
> 
> s/as far as possible, be self-configuring./as far as possible, be
> self-configuring, or manual configuration should be kept to a minimum,
> and possibly aided by user-friendly "wizard" configuration tools./

I think you mean 3.3?  If so, this uses the phrase 'as far as possible'.  I have also changed 'must be unmanaged' to add the same qualification in response to Mike's email.

> Section 3.3.1
> 
> 3 realms gives 3 borders.
> 
> s/ then the borders will include that from the homenet to the ISP, and
> that from the homenet to a guest network./ then the borders will include
> that from
>   the homenet to the ISP,that from the guest network to the ISP, and
> that from the homenet to a guest network./

Changed.

> Section 3.4.1
> 
> / ULAs should be used within the scope of a homenet to support routing
> between subnets regardless of whether a globally unique ISP-provided
> prefix is available./
> 
> Do we have sufficient knowledge of the current state of play of ULA
> implementations running in parallel with GUA to be able to make this a
> "should"? Personally, I'd be perfectly happy with a GUA address scheme
> as long as my provider gave me DHCP-PD lease times that were an order of
> magnitude longer than any typical outage (say a week compared to a one
> day's down-time). On the other hand ULA-only operation should definitely
> be supported in stand-alone homenets.

We have had this discussion a few times, and the included text was the consensus, i.e. a homenet should run GUA alongside ULA, rather than just using the most recent valid GUA.

Very happy to hear other comments as to whether there's been a shift here.

> Section 3.4.4
> 
> / In cases where two /48 ULAs are generated within a homenet, the
> network should still continue to function./ In cases where two /48 ULAs
> are generated within a homenet, the network should still continue to
> function, meaning that both ULA prefixes should be used for delegation
> throughout the homenet./

Do they both need to be delegated, or just routed?  For example if two LLN network gateways pick their own /48?  Perhaps something like " meaning that hosts will need to determine that each ULA is local to the homenet."?

> Section 3.5.1
> IPv4 is out of scope.

3.6.1 I think.

> s/In IPv4 NAT networks, the NAT provides an implicit firewall function.
> [RFC4864] describes a "Simple Security" model for IPv6
> networks,/[RFC4864] describes a "Simple Security" model for IPv6 networks,/
> 
> s/RFC 4864 implies an IPv6 "default deny" policy for inbound connections
> be used for similar functionality to IPv4 NAT./RFC 4864 implies an IPv6
> "default deny" policy for inbound connections./
> 
> s/It should be noted that such a "default deny" approach would
> effectively replace the need for IPv4 NAT traversal protocols with a
> need to use a signalling protocol to request a firewall hole be
> opened./It should be noted that such a "default deny" approach would
> require use of a signalling protocol to request a firewall hole be
> opened for inbound connectivity./

I think it's useful here to compare the IPv6 approach to what's commonplace today for IPv4 homenets.  So personally I'd prefer to keep this as is.

> Section 3.6.5
> s/This could then be used with security settings to designate where a
> particular application is allowed to connect to or receive traffic
> from./This could then be used with security settings to designate
> between which nodes a particular application is allowed to communicate,
> provided ULA address space is filtered appropriately at the boundary of
> the realm./

Changed.

> Section 3.7.1
> /whether support may be required for IPv6 multicast routing across the
> scope of the whole homenet/
> 
> Section 3.5.1. has already said multicast routing is "desirable", which
> I consider a mistake in an environment with so many battery-powered
> devices. Even in wired devices, power consumption is becoming more
> important (see banning incandescent electric light bulbs), so we should
> allow devices to enter a low power state whenever possible should they
> so desire.

I have edited 3.5.1 to make this concern/limitation clearer, and removed mention of it here.

> I think 3.7.1 is more accurate. If site-wide service discovery via
> multicast is required, it probably implies that site-wide multicast
> routing is required (unless someone comes up with a subnet to subnet
> name space forwarder that can take part in two disjoint link-local
> multicast domains and cope with large-scale topology loops). I don't
> consider multicast routing in homenet "desirable" on its own.

Agreed.

> Section 3.7.3
> 
> /the homenet will need to uck and tse a local name space/  ?

It seems I submitted the pre-ipsell .txt file, sorry :)

> I definitely prefer ULQDN to ALQDN.
> 
> I still to remain to be convinced why the default name space  & name
> serving scenario cannot be
> 1) that an IPv6 CER acts as a DHCPv6-PD client
> 2) that this also triggers the CER to become an authoritative DNS server
> for the homenet (advertised to local nodes via DHCPv6 or RA, togetehr
> with appropriate domain search list),
> 3) that the ISP delegates the reverse resolution zone related to the PD
> lease to this customer-controlled DNS server
> 4) plus provides a delegated forward resolution zone to the homenet for
> the customer to populate e.g. customerXXXX.isp.net on the
> customer-controlled DNS server
> If the ISP link goes down, the user can still resolve their own local
> names (on their own server)
> 5) If necessary we hide that ISP defined zone in another user friendly name
> 6) The ISP provides secondary (off site) back up for the user-controlled
> primary server, via standard DNS zone transfers
> 7) or the user signs up to a dyndns type service or other DNS service
> outside of the ISP if she wants to use her own DNS domain.
> 
> It's the way we've done delegation for years elsewhere on large
> networks, so why not in the home networks too?

I believe the current text is fully in line with such an approach - if it isn't, please highlight where so we can update it.

> Section 3.7.4
> 
> /It is highly desirable that the homenet name service must at the very
> least co-exist with the Internet name service./
> 
> I would submit that it is highly desirable that the homenet name service
> IS the Internet name service.
> No gateways. No proxies. No 2 way synching of content. No timeout
> synchronisation problems.
> No 2nd guessing authority. No complexity of extending DNS e.g. via DNSSEC.
> No problems with highly mobile devices changing tethering.
> 
> /As described in [I-D.mglt-homenet-naming-delegation], one approach is
> to run an authoritative name service in the homenet, most likely on the
> CER, which caches results, and to have the homenet's ISP provide a
> secondary name service./
> 
> This exactly matches my comment above for 3.7.3. And I think this draft
> is an excellent straw man that any alternatives should have to beat to
> be considered for inclusion in homenet as the default solution. I have
> no problem with "better" or "extended", if that can be clearly demonstrated.

OK, I think we're in agreement here then :)  If not, please clarify.

> /This might imply that state information should be distributed in the
> homenet, to be recoverable by/to the new CER./
> Or backed up to a configuration server hosted at the ISP? e.g. a new DNS
> primary could populate itself from the ISP secondary server if it
> detects it has a blank zone file (by querying your own zone name for NS
> glue records in the delegating DNS).

Yes, that could be an ISP service.  I'll add text.

> Section 3.7.7
> Must also include search domains for local FQDN-derived zones.

Added.

> Nits
> ====
> 
> s/homenet/Homenet/g ?

I'm OK with little h.

> s/and is thus need not be/and thus need not be/
> 
> Section 2.5
> s/it is better to not expose/it is better not to expose/
> 
> s/ideally zero configuration/minimal, and ideally zero configuration/
> 
> Section 3.2.1
> s/Routing cycles within a topology are in a sense good in that they
> offer redundancy./Loops within a routed topology are in a sense good in
> that they offer redundancy./
> s/Bridging cyslces can be dangerous /Bridging loops can be dangerous /
> s/It is only cycles using simple repeaters/It is only loops using simple
> repeaters/

Corrected - I thought I'd nailed all those!

> Section 3.2.2
> 
> s/Some may or may not be walled gardens./Some may or may not provide a
> default route to the Pubic Internet./
> 
> 
> Section 3.5.1.
> s/Where multicast is routed cross a homenet/Where multicast is routed
> across a homenet/
> 
> Section 3.6.3
> s/testomony/testimony/
> 
> Section 3.7.5
> s/ISP should should not /ISP should not /
> 
> Section 3.7.6
> s/dicovery/discovery/

All nabbed, thanks - my ispell mistake, sorry.

>> The open issue is whether the LQDN should be used alongside a global
>> FQDN if one is available (with appropriate mappings/CNAMEs and reverse
>> entries to the global FQDN as proposed I think by Curtis), or if the
>> global domain is available then no local domain should be used. 
> I prefer the latter.

OK, that's pretty much what 3.7.3 says.  Thanks.

> To me the easiest way to achieve a simple and clear
> implementation is to define that a homenet is either stand-alone (with
> ULA + local name space) or "normally attached" (with FQDN and GUA and
> sufficient timers and caches to keep it up during temporary outages of
> the ISP link). I suspect that implementing "sometimes attached" homenets
> with coexistence of ULA & GUA and LQDN & FQDN is going to be a lot
> tougher. But maybe some developers can jump in and keep me honest on
> that assumption.
> 
> regards,
> RayH

Thanks for all the comments. -06 will be out very soon.

Tim

> 
>> 
>> One item where there seemed to be a lack of a firm conclusion (despite
>> some firm statements each way) was the question of using a single
>> global name space or separate internal and external name spaces. The
>> current text essentially says:
>> * The default is to use an ISP-provided domain in the homenet, but
>> with the user able to use an independent domain name instead if preferred.
>> * If no global domain is available, the homenet uses either a ULQDN
>> (preferred) or ALQDN, and these are scoped to the local homenet (i.e.
>> the homenet can only be reached remotely if using a global domain).
>> 
>> 
>> 
>> Tim
>> 
>> On 19 Oct 2012, at 17:00, [e-mail]
>> <mailto:[e-mail]> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Home Networking Working Group of the
>>> IETF.
>>> 
>>> Title           : Home Networking Architecture for IPv6
>>> Author(s)       : Tim Chown
>>>                         Jari Arkko
>>>                         Anders Brandt
>>>                         Ole Troan
>>>                         Jason Weil
>>> Filename        : draft-ietf-homenet-arch-05.txt
>>> Pages           : 43
>>> Date            : 2012-10-19
>>> 
>>> Abstract:
>>>  This text describes evolving networking technology within
>>>  increasingly large residential home networks.  The goal of this
>>>  document is to define an architecture for IPv6-based home networking,
>>>  while describing the associated principles, considerations and
>>>  requirements.  The text briefly highlights the specific implications
>>>  of the introduction of IPv6 for home networking, discusses the
>>>  elements of the architecture, and suggests how standard IPv6
>>>  mechanisms and addressing can be employed in home networking.  The
>>>  architecture describes the need for specific protocol extensions for
>>>  certain additional functionality.  It is assumed that the IPv6 home
>>>  network is not actively managed, and runs as an IPv6-only or dual-
>>>  stack network.  There are no recommendations in this text for the
>>>  IPv4 part of the network.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-homenet-arch
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-homenet-arch-05
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-05
>> 
> 
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet