Re: Proposed update to ULA Draft (-09)

[Brian E Carpenter <[e-mail]>]

I support this version. Although I don't fully agree with
the concerns expressed by some IESG members, I think this
new version is quite OK, and the quickest way make ULAs
available to networks that need them.

    Brian

Brian Haberman wrote:
> IPv6 WG,
> 
> In order to resolve the last IESG discuss comment on the ULA draft two  
> sets of changes are proposed.  Sam Hartman, who holds the Discuss, has  
> reviewed these changes and said these proposed changes resolve the  
> Discuss.  The changes are:
> 
>       o Removed all mention of centrally assigned IPv6 local address
>         addresses based on IESG comments.  L=0 is left to be defined in
>         the future.
> 
>       o Added new section titled "Global Routing Considerations" that
>         discusses the issues relating to why using these addresses for
>         general purpose unicast address on the global internet is not a
>         good idea.
> 
> An updated draft with the proposed changes can be found at:
> 
>    http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr 
> -09.txt
> 
> along with an diffed version (-09 vs. -08) at:
> 
>    http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr 
> -09.html
> 
> (Note the htmldiff that was used to produce the html diff file got a  
> little confused in places, but it is still useful to see the changes).
> 
> The new section 5.0 is also attached inline below.
> 
> We wanted the working group to review the proposed changes before a new  
> version was submitted.
> 
> Thanks,
> Bob Hinden / Brian Haberman
> IPv6 working group chairs
> 
> ----------------------------
> 
> 
> 5.0 Global Routing Considerations
> 
>    Section 4.1 provides operational guidelines that forbid default
>    routing of local addresses between sites.  Concerns were raised to
>    the IPv6 working group and to the IETF as a whole that sites may
>    attempt to use local addresses as globally routed provider-
>    independent addresses.  This section describes why using local
>    addresses as globally-routed provider-independent addresses is
>    unadvisable.
> 
> 5.1 From the Standpoint of the Internet
> 
>    There is a mismatch between the structure of IPv6 local addresses and
>    the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
>    local addresses fits nowhere in the normal hierarchy of IPv6 unicast
>    addresses.  Normal IPv6 unicast addresses can be routed
>    hierarchically down to physical subnet (link) level and only have to
>    be flat-routed on the physical subnet.  IPv6 local addresses would
>    have to be flat-routed even over the wide area Internet.
> 
>    Thus, packets whose destination address is an IPv6 local address
>    could be routed over the wide area only if the corresponding /48
>    prefix were carried by the wide area routing protocol in use, such as
>    BGP.  This contravenes the operational assumption that long prefixes
>    will be aggregated into many fewer short prefixes, to limit the table
>    size and convergence time of the routing protocol.  If a network uses
>    both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
>    types of address will certainly not aggregate with each other, since
>    they differ from the most significant bit onwards.  Neither will IPv6
>    local addresses aggregate with each other, due to their random bit
>    patterns.  This means that there would be a very significant
>    operational penalty for attempting to use IPv6 local address prefixes
>    generically with currently known wide area routing technology.
> 
> 5.2  From the Standpoint of a Site
> 
>    There are a number of design factors in IPv6 local addresses that
>    reduce the likelihood that IPv6 local addresses will be used as
>    arbitrary global unicast addresses.  These include:
> 
>       - The default rules to filter packets and routes make it very
>         difficult to use IPv6 local addresses for arbitrary use across
>         the Internet.  For a site to use them as general purpose unicast
>         addresses, they would have to make sure that the default rules
>         were not being used by all other sites and intermediate ISPs
>         used for their current and future communication.
> 
>       - They are not mathematically guaranteed to be unique and are not
>         registered in public databases.  Collisions, while highly
>         unlikely, are possible and a collision can compromise the
>         integrity of the communications.  The lack of public
>         registration creates operational problems.
> 
>       - The addresses are allocated randomly.  If a site had multiple
>         prefixes that they wanted to be used globally the cost of
>         advertising them would be very high as they could not be
>         aggregated.
> 
>       - They have a long prefix (i.e, /48) so a single local address
>         prefix doesn't provide enough address space to be used
>         exclusively by the largest organizations.
> 
> ---------------------
> 
> 
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------