Subject: Proposed update to ULA Draft (-09)

From: Brian Haberman <[email-masked]>
Date: Fri, 14 Jan 2005 19:09:46 -0500

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jan 2005 10:49:33 +0100

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jan 2005 23:10:34 +1030

Hi Bob, Brian,

I'm a bit concerned about this suggestion, in section 4.1, Routing :

(as a side note, this is from Rev 8, the nokia web site resolves to an
IPv6 address, I don't seem to be able to get to it via my 6to4
connection though)

   For link-state IGPs, it is suggested that a site utilizing ULA
   prefixes be contained either within one IGP domain or area.  By
   containing a ULA prefix to a single link-state area or domain, the
   distribution of prefixes can be controlled.

I think it potentially could cause conflicts with the idea of using the
same subnet numbers as those used with a global prefix.

Most entities (organisations, individuals etc) who might use Local Ipv6
addresses may also be assigned a single global /48, as per the RFC3177
recommendation.

If an organisation follows the above suggestion, they may end up with a
number of ULA /48s, in particular if they generate a new ULA per IGP
area. Naively, they may, within the each area or IGP domain, assign
subnet numbers starting at 0x0001. In other words, within an area or IGP
domain, use a local 2^16 subnet address space.

This is probably reasonable and even preferred, as the length of time
the organisation "owns" its ULA address spaces is (likely to be) much
longer than the time they hold a global prefix. Focusing on the
available ULA address space while planning the subnet structure makes
sense.

The problem would occur when they try to assign these same subnet
numbers to a single, global /48 they've been assigned. Of course, they
couldn't, as they'd now be trying to assign multiple "subnet 0x0001"s
within the single, global /48. They'd be forced to use different subnet
numbers for their global and ULA prefixes.

If they were less naive, they might assign ranges of non-overlapping
subnet numbers to the different areas or IGP domains within the ULA
/48s, then allowing them to have unique subnets within the single,
global /48 they've been assigned. In other words, the subnet space they
assign subnets out of is a single range of 2^16 across their network.
This introduces complexity though, as they'll now have to configure
prefix summarisation on the area or IGP domain at different points
within the ULA and global address spaces. E.g., for the ULA assignments,
they can summarise at the /48 point, where as for the single global /48
assignment, they might summarise at, for example, the /56 point. It gets
a bit more complicated if they need to use variable length subnets
within their global IPv6 prefix. I don't think this is overly complex,
however I think it defeats the simplicity goals of either a ULA prefix
per IGP domain or area, or using common subnet numbers for ULA and
global prefixes.

I'm not sure what my opinion is regarding which addressing model would
be best, and maybe there isn't one "best" one. I suppose both of them
could be suggested, with the caveats of each of them described.
Possibly, it may be outside of the scope of this RFC. More discussion
might help.

Thanks,
Mark.

-- 

    "This signature intentionally left blank."

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jan 2005 23:39:48 +1030

On Mon, 17 Jan 2005 23:10:34 +1030

> Possibly, it may be outside of the scope of this RFC. More discussion

Or, to get this ID moving, remove both suggestions, and leave this
issue to be addressed somewhere else.

Regards,
Mark.

--

---

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Jan 2005 11:19:55 -0800

Mark,

Combining your two emails.

>same subnet numbers as those used with a global prefix.

The language "it is suggested" was chosen to allow flexibility.  As you 
point out in large multi domain/area deployments there are reasons to do it 
differently.

>issue to be addressed somewhere else.

In my personal view, this would be the best course for now.  Later on it 
would be good to get feedback on how people deploy ULAs in operational 
networks.  For example, this might be a good activity for v6ops.  Actually, 
I would be surprised if there wasn't a lot of interest in tracking 
deployment and operational experience.

Thanks,
Bob

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 17 Jan 2005 13:57:04 -0600

Thus spake "Bob Hinden" <[email-masked]>
> point out in large multi domain/area deployments there are reasons to do
it

I think removing "area" and just leaving "domain" makes more sense; I can't
see anyone actually deploying different ULA prefixes per area.  The only
possible justification would be different ULAs per business unit (to prepare
for sell-offs) but business unit lines are rarely reflected in topology, in
my experience.

Also, why does this suggestion only apply to link-state IGPs?  What are our
recommendations for people using RIPv6, EIGRPv6, etc?  Or with internal BGP
peering between multiple IGPs?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Brian Haberman <[email-masked]>
Date: Mon, 17 Jan 2005 15:49:10 -0500

On Jan 17, 2005, at 14:57, Stephen Sprunk wrote:

>> point out in large multi domain/area deployments there are reasons to  
>> do
> it
>> differently.
>

This change was made to address a DISCUSS comment specifically talking  
about
link-state routing protocols and area boundaries.  The text of the  
comment
is available at  
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_comment&id=26775.

> peering between multiple IGPs?

Distance-vector protocols are not generally broken up into admin areas  
like
OSPF & IS-IS.  I used to run a modified ripv6 daemon that routed the  
original
site-locals without issues (wrt internal routing).  So, I don't see  
much need in
giving a bunch of guidance there.

As to internal BGP, my question is "How many scenarios do we want to  
carry
around in this document?

Regards,
Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 17 Jan 2005 18:33:08 -0600

----- Original Message ----- 
From: "Brian Haberman" <[email-masked]>
To: "Stephen Sprunk" <[email-masked]>
Cc: "Bob Hinden" <[email-masked]>; "Mark Smith"
<[email-masked]>; <[email-masked]>
Sent: Monday, January 17, 2005 14:49
Subject: Re: Proposed update to ULA Draft (-09)

> >> The language "it is suggested" was chosen to allow flexibility.  As
> >> you point out in large multi domain/area deployments there are
> >> reasons to do it differently.
> >
> > I think removing "area" and just leaving "domain" makes more
> > sense; I can't see anyone actually deploying different ULA prefixes
> > per area.  The only possible justification would be different ULAs
> > per business unit (to prepare for sell-offs) but business unit lines
> > are rarely reflected in topology, in my experience.
>
> This change was made to address a DISCUSS comment specifically
> talking about link-state routing protocols and area boundaries.  The
> text of the comment is available at

I can't find a way to agree with Alex's comments.  A "site" certainly can't
be (productively) smaller than a link-state area due to flooding, but it can
certainly be bigger than an area and even span domains if they're under the
same administrative control.

Part of the problem is "site" has been overloaded to mean "administrative
domain", whereas the common meaning is a single physical location.  Neither
makes sense to me in the 09 text, though.

> > Also, why does this suggestion only apply to link-state IGPs?
> > What are our recommendations for people using RIPv6, EIGRPv6,
> > etc?  Or with internal BGP peering between multiple IGPs?
>
> like OSPF & IS-IS.

EIGRP is often broken up into "areas" of a sort due to summarization, and
the consequent limitation of routing updates appears similar to link-state
protocols.  With EIGRP v1.1, each physical site may end up being a "stub"
area; should every location then get its own ULA prefix, even if it only has
one router?

> I used to run a modified ripv6 daemon that routed the original
> much need in giving a bunch of guidance there.
>
> As to internal BGP, my question is "How many scenarios do we
> want to carry around in this document?

I question whether we should carry any.  The only strong requirement is that
a "site" be contained within a single AS, regardless of how many routing
protocols or areas it contains.  Network engineering dictates how many
prefixes will be required in a given site's configuration.

S

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jan 2005 15:09:47 +1030

On Mon, 17 Jan 2005 18:33:08 -0600

> makes sense to me in the 09 text, though.

Maybe it would be better to be even more generic and abstract about the
scope of these addresses, and have some text similar to the following.
This would eliminate specific reference to certain technologies and the
different scenarios and execeptions that can be created with them :

"Addresses and prefixes allocated from within one or more /48 ULA
address spaces are only to be visible within the administrative domain
of the network in question. Traffic with ULA sources and / or
destinations and route advertisements containing ULA prefixes should
(SHOULD(?)), by default, be prevented from leaving or entering the
administrative domain."

The edge of the administrative domain may coincide with the edge of a
BGP AS, an IGP domain, or the boundary between a service provider and
customer, in the case where static routing is being used."

And then the text referring /48 or longer exceptions such as the VPN
case, merging of organisations etc.

As much as it would be good to stay generic, identifying BGP as a
special case with a default block on the ULA /7 prefix would probably be
best as non-intentional leaking of ULA address spaces could have global
consequences. Other than that though, I think it would be better not to
identify or suggesting boundaries to constrain ULA prefixes to, such as
IGP areas.

Regards,
Mark.

--

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2005 08:23:26 +0100

Bob Hinden wrote:
> point out in large multi domain/area deployments there are reasons to do 
> it differently.
> 
> networks.  For example, this might be a good activity for v6ops.  
> Actually, I would be surprised if there wasn't a lot of interest in 
> tracking deployment and operational experience.

I guess. It's a shame this point didn't come up during Last Call.
If we change something other than what the IESG asked us to change,
we are on the edge of a process problem. I though that lower-case
"suggested" was OK - it's much weaker than an official SHOULD, which
would certainly be a mistake for the reasons Mark gave.

    Brian C

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Jan 2005 17:40:57 +0200 (EET)

> We wanted the working group to review the proposed changes before a new 

I see no big problem with the changes, but the bullet point one of the 
changes refers to was this:

    The default behavior of exterior routing protocol sessions between
    administrative routing regions must be to ignore receipt of and not
    advertise prefixes in the FC00::/7 block.  A network operator may
    specifically configure prefixes longer than FC00::/7 for inter-site
    communication.

    If BGP is being used at the site border with an ISP, the default BGP
    configuration must filter out any Local IPv6 address prefixes, both
    incoming and outgoing.

This was discussed (without a resolution) in November:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03898.html

This 'default behaviour must be to ignore' seems rather inpractical to 
implement from vendor's perspective (unless you create a special knob 
'allow-ula' applicable to eBGP).  Therefore I'm doubtful whether it 
gets implemented..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Tue, 18 Jan 2005 07:41:02 -0800

Brian,

>would certainly be a mistake for the reasons Mark gave.

To clarify, I read Mark's text ("remove both suggestions") as "remove both 
of the suggestions he made in his email" and to not change the current 
text.  Mark should verify this.

I agree with your points that changing this text at this point will require 
going back to the ADs to revisit the issue and I don't think the further 
delay is worth it.

Bob

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jan 2005 09:43:12 +1030

On Tue, 18 Jan 2005 07:41:02 -0800

> text.  Mark should verify this.

I was thinking, because of the conflicts, delete both the text
suggesting that subnet numbers would be shared between ULA and global
prefixes, and the suggestion for separate ULA /48 prefixes per IGP
domain or area. I'd think making no recommendation would be better than
making ones that may need to be clarified or contradicted at a later
date.

Regards,
Mark.

--

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Jan 2005 01:40:32 -0800

I agree this version is fine and needs to be out the door already. There
area a number of conflicting trade-offs in address management and as such
there will never be a one-size-fits-all solution that the IESG seems to so
desperately want. This document spells out a need, discusses alternatives
then shows how to fill it, and explains why this approach should not be used
to solve unrelated problems. There is nothing more it can do so it is time
to ship it.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Monday, January 17, 2005 1:50 AM
> To: Brian Haberman
> Cc: Bob Hinden; IPv6 WG

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 19 Jan 2005 11:46:50 +0000

Hi.

Overall this should be out there rsn.

However, there are is one point that needs clearing up in the estimation of 
collision probability (S3.2.3):
In para 2 (above the formula), N is stated to be the total number of such 
IDs whereas in parentheses after the formula N is defined to be the number 
of connections).  I believe what is meant is that N is the total number of 
Global IDs that are interconnected.  Also suggest the phrase after the 
formula would be better as:

    where P is the probability of collision, N is the number
    Global IDs interconnected and L is the length of the global ID.

Few minor wording grumbles:
S3.1.1, last para: Trillion is not an internationally unique term: 
s/trillion/*10^12/
S3.2.1, para 1: The second sentence doesn't say quite what it means now:
s/
    It is important to ensure a reasonable
    likelihood of uniqueness that all sites generating a Global IDs use a
    functionally similar algorithm.
/
    It is important that all sites generating Global IDs use a functionally
    similar [equivalent??] algorithm to ensure there is a reasonable
    likelihood [high probability???] of uniqueness.
/
I have vague recollections that the word 'similar' was settled on here 
after considerable discussion.

Many places (S3.1 (3 places), S3.1.1 (3 places), S3.2.1 (2 places), S3.2.2 
(2 places), S3.2.3(8 places), S6.2): Capitalization of Global ID is not 
consistent: s/global ID/Global ID/

S3.2.2, last para; S4.4 (2 places): s/local IPv6/Local IPv6/

S4.3, paras 2 and 3: There seems to be some duplication of words here: The 
"reject" route is installed twice and ICMPv6 considerations are 
duplicated.  I am not sure if these were originally intended to say 
different things?

S4.5: s/reachable any point/reachable at any point/

S4.6: s/automatically the way/automatically in the way/
S5.0, first para: s/unadvisable/inadvisable/ [OK... this is a personal thing]

Regards,
Elwyn

>Discuss.  The changes are:
<<snip>>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Jan 2005 11:43:06 -0800

Elwyn,

At 03:46 AM 01/19/2005, Elwyn Davies wrote:
>However, there are is one point that needs clearing up in the estimation 
>of collision probability (S3.2.3):

I agree.  It the text after the formula should be:

    approximates the probability of collision (where N is the number
    interconnections global IDs and L is the length of the global ID).

>Few minor wording grumbles:

Thanks for the editorial suggestions.  I will incorporate them as 
appropriate in the next draft.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Jan 2005 11:51:26 -0800

Pekka,

>I see no big problem with the changes, but the bullet point one of the

Thanks.  Good to hear!

>'allow-ula' applicable to eBGP).  Therefore I'm doubtful whether it gets 
>implemented..

I think this was responded to:

    http://www1.ietf.org/mail-archive/web/ipv6/current/msg03901.html

This is mean as operational guidelines.  We are not precluding a vendor 
from implementing such a "knob", but do not require it.  This is based on 
discussion with the routing ADs as part of their review of the document.

Regards,
Bob

---

From: Brian Haberman <[email-masked]>
Date: Thu, 20 Jan 2005 17:06:06 -0500

<Shepherding WG Chair Hat=on>

      Given that the changes proposed to the ULA spec are in response to
IESG Discuss comments, I have not seen reasonable justification
to make any of the functional changes mentioned in this thread.
Given that, I am directing Bob to only incorporate editorial changes
where necessary.

      For those of you who did make technical comments on the
operational guidelines in the document, the goal is to use get the ULAs
out so that they can be used and feedback gathered on their behavior.
At that time, the spec will be open for modifications as they are 
needed.

Regards,
Brian

<Shepherding WG Chair Hat=off>