Subject: IPv6 ULA

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 10 Nov 2004 21:55:04 +0900 (JST)

there are a large volume of discussion on nanog list on IPv6 ULA.
	you may want to check it out.

itojun

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

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 10 Nov 2004 23:04:52 +0900 (JST)

> 	you may want to check it out.

	http://www.merit.edu/mail.archives/nanog/

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2004 16:22:26 +0100

It's no surprise that some ISP people see some disadvantages
to ULAs, but I think we knew that a long time ago. I believe
that we already balanced the potential disadvantages to ISPs
against the known advantages for user sites. I see ULAs as
partly compensating user sites for the known disadvantages
of the strict PA model adopted for IPv6.

Of course, if the ISP community has constructive suggestions
to improve the centrally-assigned ULA model, that would be great.
It's very late for draft-ietf-ipv6-unique-local-addr-07.txt.

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 11 Nov 2004 14:49:50 -0800

During a bar discussion very late last night an issue was raised about lack
of clarity, but I am sure we need to put more thought into the remedy than I
will suggest. In any case, the issue is that by leaving the filtering action
as an operational topic we invite restraint of trade complaints. Basically
nobody is in the position to tell someone else that they Must/Should filter
FC00::/7 without the lawyers circling. The current text tries to cover the
case, but leaves it unclear if the action is operational or vendor
implementation. Given how tired I am, I am sure I am not doing much better
...

Proposed remedy: change the third paragraph of 4.0
remove:
'Any router that is used between sites must be configured to filter out any
incoming or outgoing Local IPv6 unicast routes. The exception to this is if
specific /48 or longer IPv6 local unicast routes have been configured to
allow for inter-site communication.'

replace with:
'The behavior of exterior routing protocol sessions between administrative
routing regions MUST be to ignore receipt of and not advertise the FC00::/7
prefix. A network operator MAY specifically configure prefixes longer than
FC00::/7 for inter-site communication.'

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, November 10, 2004 7:22 AM
> To: Jun-ichiro itojun Hagino
> Cc: [email-masked]
> Subject: Re: IPv6 ULA
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 12 Nov 2004 06:00:30 -0800

Tony,

>implementation. Given how tired I am, I am sure I am not doing much better

Based on an IESG discuss comment, the next version will move the 
operational related sections into one section titled "operational 
guidelines".   I think this will help make it clear these are 
recommendations/suggestions as to avoid the situation where we are telling 
the operators what to do.  The choice of lowercase must/should was 
deliberate as well.

>FC00::/7 for inter-site communication.'

These changes are fine with me (except changing MUST to lower case) and I 
agree that they help clarify the issue being raised on Nanog and Arin lists.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2004 15:08:13 +0100

> FC00::/7 for inter-site communication.'

I think that is an improvement.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Nov 2004 17:22:07 +0200 (EET)

> FC00::/7 for inter-site communication.'

So, are you requiring that BGP will have to have a configuration knob 
to to special-case fc00::/7? (This cannot be done using the typical 
route-map/policy statements, because it has to be on by default and 
not interfere with the operators configuring their own policy.)

Has this been reviewed by the idr working group?

To be fair, I think the earlier draft also seemed a bit inappropriate.

-- 
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: "Tony Hain" <[email-masked]>
Date: Fri, 12 Nov 2004 07:38:07 -0800

> not interfere with the operators configuring their own policy.)

The point would be to allow operators to express whatever policy they want
to, but they would have to explicitly configure something to override the
default black hole. The goal is not to make it difficult for people to do
the right thing, at the same time avoid having clueless operators announcing
these prefixes. By putting the requirement on the vendors we avoid telling
operators how to run their networks.

> Has this been reviewed by the idr working group?

No. It doesn't make sense to go there unless we agree on what the goal is.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Nov 2004 07:46:34 -0800

> I think that is an improvement.

Well rereading that, it still does not solve the problem. That wording would
only block advertisements of the entire /7. How about:

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.

Tony

---

From: Bob Hinden <[email-masked]>
Date: Fri, 12 Nov 2004 07:59:15 -0800

Pekka,

At 07:22 AM 11/12/2004, Pekka Savola wrote:
>So, are you requiring that BGP will have to have a configuration knob to 
>to special-case fc00::/7? (This cannot be done using the typical 
>route-map/policy statements, because it has to be on by default and not 
>interfere with the operators configuring their own policy.)

Not exactly.  The intent is to suggest that border routers be configured to 
do this.  We are not requiring knobs or special case code for this.

>Has this been reviewed by the idr working group?

There has been review from the routing ADs and the routing directorate.

>To be fair, I think the earlier draft also seemed a bit inappropriate.

The intent is to suggest some operational guidelines.  This seems like a 
reasonable approach to me.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Nov 2004 18:07:27 +0200 (EET)

On Fri, 12 Nov 2004, Bob Hinden wrote:
>> So, are you requiring that BGP will have to have a configuration knob to to 
>> special-case fc00::/7? (This cannot be done using the typical 
> Not exactly.  The intent is to suggest that border routers be 
> configured to do this.  We are not requiring knobs or special case 
> code for this.

This is slightly different than what Tony is proposing, but let me 
state the problems I see with both:

  1) operator configuration: many operators probably won't do that 
unless they have set up filters (many have, from 6bone times) to weed 
out unexpected prefixes.

  2) vendor code: the only way to implement this in the sane manner 
would be having a 'allow-ula' -like knob for BGP.  You cannot 
configure this in the policies, because either a) the operator forgets 
about ULAs when writing the policy, or b) the policy does not exist 
and it isn't applied.

So both would appear to have their problems, but 1) might be slightly 
better, especially if GROW WG would produce a BCP or some other 
document giving guidance on filtering.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 12 Nov 2004 12:46:51 -0800

Pekka Savola wrote:
> This is slightly different than what Tony is proposing, but 
> let me state the problems I see with both:
> 
>   1) operator configuration: many operators probably won't do 
> that unless they have set up filters (many have, from 6bone 
> times) to weed out unexpected prefixes.
> 
>   2) vendor code: the only way to implement this in the sane 
> manner would be having a 'allow-ula' -like knob for BGP.  You 
> cannot configure this in the policies, because either a) the 
> operator forgets about ULAs when writing the policy, or b) 
> the policy does not exist and it isn't applied.
> 
> So both would appear to have their problems, but 1) might be 
> slightly better, especially if GROW WG would produce a BCP or 
> some other document giving guidance on filtering.

Think in terms of the clueless operator that doesn't read BCP's or even know
they exist. My initial thought was a defaultl policy of FC00::/7 ->
/dev/null. This would allow any longer prefix to override, but would also
require explicit action to do so. Thinking in terms of BGP, the language of
accept/announce makes more sense, but as you note would require a knob to
allow any explicit action to override it. As I said, I am sure the text
needs work, but there appears to be a growing concern that 'just leave it to
the operators' is not going to work.

Tony