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

[Ray Hunter <[e-mail]>]

Tim Chown wrote:
> Hi all,
>
> The architecture text has been updated to -05.
>
> See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05
>
> We can take comments towards a -06 over the weekend.  The most
> substantial changes are in the Naming and Service Discovery section
> (3.7), so if you have limited time please focus your reading there.

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.

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.

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]

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.


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

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


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.

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

Section 3.5.1
IPv4 is out of scope.

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

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


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

Section 3.7.3

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


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?


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.

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


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




Nits
====

s/homenet/Homenet/g ?

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

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

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