Subject: [homenet] comments on draft-chown-homenet-arch-00

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Oct 2011 16:24:32 -0700

First of all I would like to thank the four authors for putting this
draft together.  It seems to be as a reasonable starting point.  We
have had quite a bit of good discussion on list, but not specifically
about the drafts we have available.

I've read this and have mostly nits about is there.  That is best put
in diffs.  I think we can add a lot which is best not done as diffs.
Below are unified diffs on the txt version indented an extra four
spaces.  The indenting should still be OK with SMTP line wrapping
(still under 78).  Annotation is not indented.

[ to extract just the diffs "grep -v '^ ' | sed 's/^    //'". ]

    --- draft-chown-homenet-arch-00.txt	2011-09-21 11:34:00.000000000 -0700
    +++ draft-chown-homenet-arch-00.chg	2011-10-13 10:20:04.000000000 -0700
    @@ -121,12 +121,14 @@
        networking technology in an increasingly broad range of devices and
        media.  This evolution in scale and diversity sets requirements on
        IETF protocols.  Some of these requirements relate to the need for
    -   multiple subnets for private and guest networks, the introduction of
    +   multiple subnets, for example for private and guest networks,
    +   the introduction of
        IPv6, and the introduction of specialized networks for home
        automation and sensors.
     
        While advanced home networks have been built, most operate based on
    -   IPv4, employ solutions that we would like to avoid such as network
    +   IPv4, employ solutions that we would like to avoid such as cascaded
    +   network
        address translation (NAT), or require expert assistance to set up.
        The architectural constructs in this document are focused on the
        problems to be solved when introducing IPv6 with a eye towards a

Nit: Multiple subnets are needed for other reasons as well.

Nit: IPv4 NAT is OK and needed in some cases.  We want to avoid
cascaded NAT.  This may remove some of the objections to anti-NAT
wording.

    @@ -183,13 +185,13 @@
           routing and security policies.
     
           Documents that provide some more specific background and depth on
    -      this topic include: [I-D.herbst-v6ops-cpeenhancements],
    +      this topic include: [I-D.herbst-v6ops-cpeenhancements expired],
           [I-D.baker-fun-multi-router], and [I-D.baker-fun-routing-class].
     
           In addition to routing, rather than NATing, between subnets, there
           are issues of when and how to extend mechanisms such as service
           discovery which currently rely on link-local addressing to limit
    -      scope.
    +      scope.  [prefix scoped anycast?]
     
           The presence of a multiple segment, multi-router network implies
           that there is some kind of automatic routing mechanism in place.

Nit: Just a note that the draft has expired.

Comment/discussion: I agree that some mechanism is needed.  This sound
like anycast with some limitations.  Some reasonable limitations might
be the globally routable prefix of the home network or the prefix of
the PI address.  There is no prefix scoped anycast (AFAIK) and this is
not a candidate for TTL based anycast.  OTOH, routing information can
provide a bounds on TTL and the anycast can ask for "any <type of
resource> within <list of prefixes>" doing a second pruning at the
application layer, or the anycast can be filtered at provider uplinks.

    @@ -353,7 +355,7 @@
                     |    Router     |                        | Provider
                     +-------+-------+                        | network
                             |                               /
    -                        | Customer                     /
    +   demarc #1 -------    | Customer                     /
                             | Internet connection         /
                             |
                      +------+--------+                    \
    @@ -361,7 +363,7 @@
                      | Customer Edge |                      \
                      |    Router     |                      /
                      +------+--------+                     /
    -                        |                             | End-User
    +   demarc #2 -------    |                             | End-User
               Local Network |                             | network(s)
                    ---+-----+-------+---                   \
                       |             |                       \

The above two diffs add an indication of two potential
homenet/provider demarcations to the figure.

    @@ -380,6 +382,35 @@
        operation this arrangement is considered equivalent to the topology
        in Figure 1.
     
    +   Two possible demarcation points are illustrated in Figure 1.  The
    +   samepossible demarcation points, while not shown, are applicable to
    +   Figure 2 as well.  The demarcation line indicates which party is
    +   responsible for configuration or autoconfiguration.
    +
    +   Demarcation #1 makes the Customer Edge Router the responsibility of
    +   the customer.  This is only practical if the Customer Edge Router
    +   can function with factory defaults installed.  The Customer Edge
    +   Router can be provided by the service provider with proper
    +   authentication information installed, or if simple enough, the
    +   customer can be relied upon to enter authentication information (at
    +   most a supplied user name and password).  Other mechanisms may be
    +   possible such as the provider supplying a USB memory with a
    +   certificate or private key file.
    +
    +   Demarcation #2 makes the Customer Edge Router the responsibility of
    +   the provider.  This may be the more common case today.  In IPv4
    +   only networks a consumer Customer Edge Router is very likely to be
    +   set up only to provide NAT on the customer side.  For a small
    +   business service one globally routable IP address or a small block
    +   of globally routable IP addresses may be made available on the
    +   customer side.  In the latter case, the customer hosts must be
    +   configured to use a fixed address rather than use DHCP and their
    +   ARP response is used to identify which hosts have been assigned a
    +   globally routable IP address.
    +
    +   Using either Demarcation #1 or Demarcation #2, this situation can
    +   be improved with IPv6 using the PD prefix capability [RFC3633].
    +
        This topology is also relatively well understood today [RFC6204],
        though it certainly presents additional demands with regards suitable
        firewall policies and limits the operation of certain applications

I did this as a diff since I don't think there would be much argument
over this except more nits on my suggested wording.  Authors please
comment.

    @@ -591,6 +622,14 @@
        the same provider, but the associated subnet(s) are isolated.  Some
        deployment scenarios may require this model.
     
    +   The demarcation point in Figure 3 and Figure 4 may be on either
    +   side of the Customer Edge Router.  In Figure 4, a different
    +   demarcation may be chosen by each of the two providers.  Figure 5
    +   requires that the demarcation be on the provider side of the
    +   Customer Edge Router due to one Customer Edge Router serving two
    +   service provider attachments.  Figure 5 is more likely to occur
    +   with small to medium business service than with consumer services.
    +
     3.2.  Requirements
     
        [RFC6204] defines "basic" requirements for IPv6 Customer Edge

I didn't mark up these figures.  This is mostly a reminder that two
providers may choose to put the demarcation in a different spot.  Note
that the provider configured router model (demarc #2) is more
problematic on the homenet side than demarc #1, but I didn't indicate
this.  The demarc #2 model is why so often there are two NATs back to
back today.

    @@ -619,12 +658,30 @@
     
        o  Network security
     
    +   The configuration of filters can be problematic if the filters are
    +   configured on the provider side of the customer/provider
    +   administrative demarcation.  This would be the Demarcation #2
    +   described in Section 3.1, which today is more common.  Providing
    +   flexibility may force a topology [we need a figure 2b - back to
    +   back routers] where the Customer Edge Router is connected only to a
    +   Customer Interior Router with the Customer Edge Router configured
    +   for transparent mode and filtering provided by the Customer
    +   Interior Router where the customer can make any changes necessary.
    +
    +   A provider which prefers Demarcation #2 can offer two options to
    +   their customers if simplicity is a goal.  One option is a default
    +   filtering configuration.  The second option at the choice of the
    +   customer is transparent mode, putting the responsibility of
    +   filtering on the customer.
    +
     3.3.  Considerations
     
        This section lists some considerations for home networking that may
        affect the architecture depending on how or if they are included.
        Comments are certainly required here.
     
    +   [Note: choice of demarcation issues could also go here]
    +
        Multihoming
     
           A home network may be multihomed to multiple providers.  This may

The first diff is a further discussion on the impact of the two places
where the demarc can be placed.  The second diff is a note that the
prior addition could be moved to considerations or kept where it is.

    @@ -647,7 +704,7 @@
           are necessary as described in [I-D.baker-fun-multi-router].  In
           the case of multiple exit routers, either the use of NAT66
           [RFC6296] or an alternative approach may be needed, e.g.
    -      [I-D.v6ops-multihoming-without-ipv6nat].  One could also argue
    +      [I-D.v6ops-multihoming-without-ipv6nat expired].  One could also argue
           that a "happy eyeballs" viewpoint, not too dissimilar to that
           proposed for multiple interface (mif) scenarios is also
           acceptable.  The central part of the arguments about IPv6

Nit:  Another expired draft.

I am also unclear as to what the "happy eyeballs" sentence is getting
at.  Could the wording please be made more clear.

    @@ -713,7 +770,7 @@
        designing these networks in the correct manner.  There is no implied
        priority by the order in which the principles are listed.
     
    -   Reuse existing protocols
    +   Reuse existing protocols where appropriate
     
           It is desirable to reuse existing protocols where possible, but at
           the same time to avoid consciously precluding the introduction of
    @@ -732,6 +789,15 @@
           Do we wish to say anything about other home networking related
           standards or groups, e.g.  DLNA?
     
    +   Avoid repeating mistakes
    +
    +      Where existing protocols or protocol usage have demonstrated
    +      significant flaws, do not resuse as-is simply because of
    +      precedence.  In such cases, the protocol may need to be extended
    +      or usage guidelines provided.  In some cases a protocol or a
    +      defined mechanism may need to be avoided.  For example, avoiding
    +      IPv6 NAT is an explicit goal.
    +
        Dual-stack Operation
     
           Any solutions for IPv6 must not adversely affect IPv4 operation.

Nit: Don't require reuse of protocols if they don't fit the problem.

Maybe the wording I have here is strong but the current situation with
NAT boxes masquerading as home routers IMO is severely broken.  You
may have guessed that I'm also not fond of bridging solutions.

    @@ -747,6 +813,8 @@
           Some discussion has also happened on mapping of external IPv6
           addresses to internal IPv4 ones.
     
    +      [Discussion IPv6 ULA plus IPv4 NAT as a transition tool.]
    +
        Largest Possible Subnets
     
           Today's IPv4 home networks generally have a single subnet, and

There was a lot of discussion on IPv6 ULA plus IPv4 NAT.

One thing that may be interesting is allowing an option to disable use
of IPv4 on the internal side.  Handing out IPv6 only and using NAT to
reach the IPv4 world may become more common in the years (or decades)
to come as transition to mostly IPv6 occurs.  Does anyone on list have
experience with this?

    @@ -881,15 +949,24 @@
           home network, and thus at least all routing devices in the
           network.
     
    -   Proxy or Extend?
    +   Proxy or Extend or Robust Solution?
     
           Related to the above, it would be desirable to decide whether in
           general existing protocols that are designed to only work within a
           subnet are modified/extended to work across subnets, or whether
           proxy capabilities are defined for those functions.
     
    -
    -
    +      Routing protocols have proven robust in topologies where proxy
    +      solutions are known to fail.  Integration of currently
    +      link-local or anycast functionality with the scope of internal
    +      routing may offer a solution.  For functionality that is
    +      currently link local, automatically configured proxy, with
    +      minimal extensions may be able to use routing information to
    +      limit scope and avoid proxy loops.  For functionality that makes
    +      use of anycast but is intended to be local, internal routing may
    +      be an appropriate scope.  Backwards compatibility is essential.
    +      The impact of bridges and legacy routers must be considered.  A
    +      important goal is to require no host changes.

     Arkko, et al.            Expires March 24, 2012                [Page 16]

The solution should be robust in any arbitrary topology.  This has
been the topic of a lot of discussion on the mailing list, with no
clear consensus on "the best routing protocol for all situations"
because such a thing may not exits.  The details of which routing
protocol to use need not be explored in this document.

    @@ -915,13 +992,25 @@
           on the availability of the ISP network at any given time, other
           than for connectivity to services or systems off the home network.
     
    +   Zero configuration or minimal configuration
    +
    +      Home networks are installed by home owners who have limited or
    +      no technical knowledge of IP, bridging or routing.  Networks
    +      should be robust regardless of topology, using a default
    +      configuration.  Minimal configuration is change is acceptable
    +      for specific tasks such as providing authentication necessary to
    +      enable customer/provider connectivity.  It should always be
    +      possible to configure routers for specific customer needs, but
    +      never necessary to do so in order to basic addressing, routing,
    +      forwarding and naming functionality to work.
    +
        Intelligent Policy
     
           As the Internet continues to evolve, no part of the architecture
           or security design should depend on hard coding acceptable or
           unacceptable traffic patterns into the devices.  Rather, these
           traffic patterns should be driven off up-to-date databases in the
    -      Internet.
    +      Internet.  [?]
     
           This principle should also cover consideration to avoid hard
           coding IP literals or taking other actions that unnecessarily

Zero config needs to be an explicit goal.

The last sentence above where I added [?]  seems like an odd and maybe
misguided requirement.  Its good to have a mechanism to update packet
filters but this seems almost like asking to fetch a URL on boot or
periodically.  One thing about firewalls is unexpected change can be
bad.  Also an automatic update to filters seems like too obvious an
attack vector.

This is the end of the nits and comments on what is there in the
document.  I suggest the authors also take a good look at the email
exchange between Peter and I and see if we can incorporate some of
those ideas into this document.  For example:

  Separation into the following issues: uplink discovery, address
  allocation, user attachment, security, routing.

As a general comment, the existing draft has more questions than
answers.  As it was intended to stir up discussion, it may have served
that sort of purpose, but if we are converging on an architecture,
then we should provide a document that provides more answers than open
questions.

So my question to the authors is whether the intent is to morph this
document into an architecture or create another document to replace
this?

Curtis