Deprecating Site Local Addresses
draft-ietf-ipv6-deprecate-site-local-03

[Ballot discuss]
I largely support the document, but have registered a DISCUSS, as I would like
the WG to consider changing the way the section on routing (2.4) sounds.

The tone of the section now is "this creates problem" and may be interpreted as
if they are technically unsolvable. This may give a wrong impression to the
future reader. I think we should change it to "this would increase router
implementation and management complexity". In other words, we could get it to
work, we know the mechanisms for that, but the complexity price is high.

Some rewording suggestions, plus some additional thoughts:

> 2.4  Router pain, routing tables
                    ^^^^^^^^^^^^^^
                    increased complexity

>    The ambiguity of site local addresses also creates problems for the
                                                        ^^^^^^^^
                                                        complications
>    routers. In theory, site local addresses are only used within a
>    contiguous site, and all routers in that site can treat them as if
>    they were not ambiguous. In practice, problem occurs when sites are
                                          ^^^^^^^^^^^^^^
                                          special mechanisms are needed
>    disjoint, or when routers have to handle several sites.

>    In theory, sites should never be disjoint. In practice, if site
>    local addressing is used throughout a large network, some elements
>    of the site will not be directly connected. This will create a
                                              ^
                      + for example, due to network partitioning

>    demand to route the site-local packets across some intermediate
>    network. In practice, this leads to an extensive use of tunneling
            ^
      + (such as the backbone area) that cannot be dedicated for
        a specific site.

>    techniques, or the use of multi-sited routers, or both.
> 
>    Ambiguous addresses have fairly obvious consequences on multi-sited
>    routers. In classic router architecture, the exit interface is a
>    direct function of the destination address, as specified by a single
>    routing table. However, if a router is connected to multiple sites,
>    the routing of site local packets depends on the interface on which
>    the packet arrived. Interfaces have to be associated to sites, and
>    the routing entries for the site local addresses are site-dependent.
>    The route management software and the routing protocols have to
>    account for the site boundaries. This can be particularly hard to do
>    when sites are adjacent or overlap.

Change the last two sentences to:

"Supporting this requires special provisions in routing protocols and techniques
for routing and forwarding table virtualization that are normally used for VPNs.
This contributes to additional complexity of router implementation and
management."

Add:

"Network management complexity is also increased by the fact that though
sites could be supported using existing routing constructs--such as domains
and areas--the factors driving creation and setting the boundaries of sites
are different from the factors driving those of areas and domains."

>    In multi-homed routers, such as for example site border routers, the
>    routing process should be complemented by a filtering process, to
>    guarantee that packets sourced with a site local address never leave
>    the site. This filtering process will in turn interact with the
>    routing of packets, as it may cause the drop of packets sent to a
>    global address, even if that global address happen to belong to the
>    target site.

"routing" should be changed to "forwarding" above.

What does "may cause the drop" mean here? As a result of a bug
or because the algorithm is not predictable?

>    In summary, the ambiguity of site local addresses makes them hard to
>    manage in multi-sited routers, while the requirement to support
>    disjoint sites creates a demand for such routers.
                  ^
              + and existing routing protocol constructs.

[Ballot comment]
>    Applications would learn or remember that the address of some
>    correspondent was "FEC0::1234:5678:9ABC", they would try to feed the
>    address in a socket address structure and issue a connect, and the
>    call will fail because they did not fill up the "site identifier"
>    variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded

Would be good to cite the document that explains the "&" syntax in
addresses.

>    Having non-ambiguous address solves a large part of the developers'

s/address/addresses/

[Ballot discuss]
> 6 IANA Considerations
>   
>    IANA is specifically requested not to reassign the 1111111011 binary
>    or FEC0::/10 prefix unless requested to do so by a future IETF
>    standards action.

Would be good to expand this to something like: 


  IANA is requested to mark the FEC0::/10 prefix as "deprecated",
  pointing to this document. Reassignment of the prefix for any usage
  requires justification via an IETF Standards Action [RFC 2434].

[Ballot discuss]
My general comment here is that I would change the tone of the section from
"this creates problem" to "this increases router implementation and management
complexity". In other words, we could get it to work, we know the mechanisms
for that, but the complexity price is high.

Some rewording suggestions, plus some additional thoughts:

> 2.4  Router pain, routing tables
                    ^^^^^^^^^^^^^^
                    increased complexity

>    The ambiguity of site local addresses also creates problems for the
                                                        ^^^^^^^^
                                                        complications
>    routers. In theory, site local addresses are only used within a
>    contiguous site, and all routers in that site can treat them as if
>    they were not ambiguous. In practice, problem occurs when sites are
                                          ^^^^^^^^^^^^^^
                                          special mechanisms are needed
>    disjoint, or when routers have to handle several sites.

>    In theory, sites should never be disjoint. In practice, if site
>    local addressing is used throughout a large network, some elements
>    of the site will not be directly connected. This will create a
                                              ^
                      + for example, due to network partitioning

>    demand to route the site-local packets across some intermediate
>    network. In practice, this leads to an extensive use of tunneling
            ^
      + (such as the backbone area) that cannot be dedicated for
        a specific site.

>    techniques, or the use of multi-sited routers, or both.
>   
>    Ambiguous addresses have fairly obvious consequences on multi-sited
>    routers. In classic router architecture, the exit interface is a
>    direct function of the destination address, as specified by a single
>    routing table. However, if a router is connected to multiple sites,
>    the routing of site local packets depends on the interface on which
>    the packet arrived. Interfaces have to be associated to sites, and
>    the routing entries for the site local addresses are site-dependent.
>    The route management software and the routing protocols have to
>    account for the site boundaries. This can be particularly hard to do
>    when sites are adjacent or overlap.

Change the last two sentences to:

"Supporting this requires special provisions in routing protocols and techniques
for routing and forwarding table virtualization that are normally used for VPNs.
This contributes to additional complexity of router implementation and
management."

Add:

"Network management complexity is also increased by the fact that though
sites could be supported using existing routing constructs--such as domains
and areas--the factors driving creation and setting the boundaries of sites
are different from the factors driving those of areas and domains."

>    In multi-homed routers, such as for example site border routers, the
>    routing process should be complemented by a filtering process, to
>    guarantee that packets sourced with a site local address never leave
>    the site. This filtering process will in turn interact with the
>    routing of packets, as it may cause the drop of packets sent to a
>    global address, even if that global address happen to belong to the
>    target site.

"routing" should be changed to "forwarding" above.

What does "may cause the drop" mean here? As a result of a bug
or because the algorithm is not predictable?

>    In summary, the ambiguity of site local addresses makes them hard to
>    manage in multi-sited routers, while the requirement to support
>    disjoint sites creates a demand for such routers.
                  ^
              + and existing routing protocol constructs.

[Ballot discuss]
Good to see this.

My Discuss can either be handled with an RFC Editor note or perhaps disputed -
shouldn't the prefix be deprecated in the IANA registry now?  Currently the IANA
considerations only say that a new value should not be registered for it without a stds
track action.

[Ballot comment]
One comment to the security considerations section by Scott Brim, GEN-AREA reviewer:

in the Security section, I would add a paragraph reiterating
of the issues due to ambiguity which were brought up in the preceding
sections.  Leakage, misrouting, etc., are noteworthy security issues.

Not worth holding the document for.

[Ballot comment]
RFC 3513 is listed as both a normative reference and an informative reference.  I would suggest striking it from the list of informative references.

Submission questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Review has been from many people in the IETF community.  I have
no concerns about the reviews performed.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

There will need to be sufficient review from the perspective of
IANA and their responsibilities with regards to this standard.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

This document captures the consensus of the WG.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The document has been contentious for quite some time.  However,
I believe that this document does represent the consensus of the
many and vocal members of the working group.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

I am unaware of any planned appeal.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  This document describes the issues surrounding the use of IPv6 site-
  local unicast addresses in their original form, and formally
  deprecates them. This deprecation does not prevent their continued
  use until a replacement has been standardized and implemented.

  - Working Group Summary

  The IPv6 working group has done extensive review of this document and
  this document reflects the consensus of the group.

  - Protocol Quality

  This document has been reviewed by members of the ipv6@ietf.org
  mailing list and by the work group chairs.