Subject: [addr-select-dt] Proposed default policy table

From: "Tony Hain" <[email-masked]>
Date: Thu, 8 Jul 2010 10:08:18 -0700

For updating 3484-revise section 2.2, the table I have been running at home
for some time is:

Precedence  Label  Prefix
----------  -----  --------------------------------
        90      0  ::1/128
        75      1  fc00::/8
        70      1  fd00::/8
        50      2  2001::/16
        50      2  2400::/8
        50      2  2600::/8
        50      2  2a00::/8
        50      2  2c00::/8
        40      3  2002::/16
        30      3  2001::/32
        20      4  ::/0
        10      5  ::ffff:0:0/96
         5      6  ::/96
         4      6  fec0::/16

The explicit label 2 set is due to a bug in the vista stack, as that should
be a single entry of 2000::/3, (and the fec0 should be /10). The differences
from the proposed one in the October text are: 
- Adding explicit entries for each half of the ULA space to prefer local
when possible (rule 2).
- Explicitly listing 2000::/3 to avoid default resulting in the ambiguous
choice of ula as src.
- Keeping teredo and 6to4 as tunnels labeled the same.
- Tunnels before default to avoid the ambiguous choices default will result
in.
- packaging all deprecated prefixes in the same label.

The currently proposed table in 2.2 does not solve the problem in 1.1, so it
would be good to move that example to an appendix or at least after the 2.2
discussion, and replace it with the one of a host selecting between Internet
access and a closed network. 

I understand the desire to move teredo to less than IPv4. While I disagree
with the premise, a resulting policy table that does that might look like:

Precedence  Label  Prefix
----------  -----  --------------------------------
        90      0  ::1/128
        75      1  fc00::/8
        70      1  fd00::/8
        60      2  2000::/3
        50      3  ::/0
        30      4  2002::/16
        20      5  ::ffff:0:0/96
         5      4  2001::/32
         1      6  ::/96
         1      6  fec0::/16

I suggest leaving 10, 40, & 80 in the precedence so people can move IPv4 or
ULA around without feeling the need to rewrite the other labels (they don't
have to, but an obvious hole to park it in reduces confusion). I haven't
tried that, and don't have time before I leave today, but I will put that in
and see how it works before the IETF meeting. It should be close to what the
current text was trying to get to, but with the explicit ula and gua
prefixes to avoid default it should work more consistently.

Tony

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Jul 2010 16:38:22 +0100

Tony,

Now that 6rd is done, what's the view on 6to4?

I know a lot of people would be quite keen to see 6to4 deprecated.

Tim

On 8 Jul 2010, at 18:08, Tony Hain wrote:

> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Jul 2010 18:13:49 +0100

For info, I have updated the dt draft with the output of the two telecons we've held:

http://www.ietf.org/id/draft-ietf-6man-addr-select-considerations-01.txt

If there are any additional changes you feel are needed before the cutoff, please email me.

Tim

---

From: Aleksi Suhonen <[email-masked]>
Date: Sun, 11 Jul 2010 23:52:17 +0000

Hi,

Tony wrote:
> I suggest leaving 10, 40,&  80 in the precedence so people can move IPv4 or
> have to, but an obvious hole to park it in reduces confusion).

The number of bits in the precedence value has not been defined, but I 
understand that most implementations use at least 32 bits anyway. I 
would like to see the default precedence values multiplied by 100 to 
leave more room for algorithmically generated entries and manual tinkering.

There are only 4 values available between fc00::/8 and fd00::/8 for 
example. Those could be easily consumed after a couple of corporate fusions.

I guess the idea has been that local administration can override all 
values to their liking. However, my understanding of the best practises 
for system and network administration is that the defaults are changed 
as little as possible. And the defaults should preferably "shine 
through" from under local modifications. This means that when the 
defaults are changed due to some software update, they might adversely 
interfere with the local changes.

I don't mind it if the default precedences are multiplied by even more 
than a hundred, I just feel it is important that there should be more 
space between the default values.

 > Precedence  Label  Prefix
  ...
 >          1      6  fec0::/16

Aren't we removing site local completely while we're at it? Or if it 
should be kept around, then why not add 3ffe::/16 too for the same reason?

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 12 Jul 2010 09:01:45 +0200 (CEST)

> I know a lot of people would be quite keen to see 6to4 deprecated.

I think 6to4 and teredo should be treated similarly - after ipv4. They 
should be used as a last resort acess to IPv6 resources. I think 
6to4 should be kept since 6to4 is the most implemented IPv6 of the CPE 
equipments.

Best Regards,
 		Janos Mohacsi

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Jul 2010 08:13:32 +0100

I have one other topic to add which I can't remember whether I posted about recently or not, so apologies if I'm repeating myself.

In undertaking some work recently on router-based hints for address selection, we found that we could improve address selection behaviour for hosts by using a new ICMP-based message to query a router or route server for an ordered list of address pairs to use for given candidate addresses.  The issue that came up was that if the host were to cache the result, and we chose to cache it within the RFC3484 policy tables, can we change/augment the current syntax/format to accommodate that?

Tim

On 12 Jul 2010, at 00:52, Aleksi Suhonen wrote:

> The number of bits in the precedence value has not been defined, but I understand that most implementations use at least 32 bits anyway. I would like to see the default precedence values multiplied by 100 to leave more room for algorithmically generated entries and manual tinkering.
> 
> There are only 4 values available between fc00::/8 and fd00::/8 for example. Those could be easily consumed after a couple of corporate fusions.
> 
> I guess the idea has been that local administration can override all values to their liking. However, my understanding of the best practises for system and network administration is that the defaults are changed as little as possible. And the defaults should preferably "shine through" from under local modifications. This means that when the defaults are changed due to some software update, they might adversely interfere with the local changes.
> 
> I don't mind it if the default precedences are multiplied by even more than a hundred, I just feel it is important that there should be more space between the default values.
> 
> Tony Hain also wrote:
> > Precedence  Label  Prefix
> Aren't we removing site local completely while we're at it? Or if it should be kept around, then why not add 3ffe::/16 too for the same reason?
> 
> -- 
> 	Aleksi Suhonen

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 12 Jul 2010 16:38:44 +0900

Hi,

> In undertaking some work recently on router-based hints for address selection, we found that we could improve address selection behaviour for hosts by using a new ICMP-based message to query a rout…

That approach also should have an issue of policy merge/conflict.

When we think about merging process, we may have to think about this
kind of approach, if we think it looks like some advantages in merging.

When we think about non-merging based solution, do we have to think
about this approach ? Which means, policy table can store one ICMPv6
message at a time ?

--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: [email-masked]

---

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 12 Jul 2010 08:34:52 +0000

> kind of approach, if we think it looks like some advantages in merging.

The Linux Way of recent days seems to be to replace /etc/<software>.conf 
with /etc/<software>.d/*.conf so in Linux specifically you could 
implement it like this:

/etc/gai.conf:
1. default rules that can be overriden
2. include instruction for /etc/gai.d/*.conf
3. system wide rules that can't be overriden

And then your address selection policy update daemon(s) would update 
their own file(s) in /etc/gai.d/ safely.

I don't have a good understanding on how other operating systems have 
implemented RFC3484 so I can't comment how universal this would be.

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 12 Jul 2010 10:53:44 +0200 (CEST)

On Mon, 12 Jul 2010, Aleksi Suhonen wrote:

>>> I have one other topic to add which I can't remember whether I posted 
>>> about recently or not, so apologies if I'm repeating myself.
>>> 
>>> In undertaking some work recently on router-based hints for address 
>>> selection, we found that we could improve address selection behaviour for 
>>> hosts by using a new ICMP-based message to query a router or route server 
>>> for an ordered list of address pairs to use for given candidate addresses. 
>>> The issue that came up was that if the host were to cache the result, and 
>>> we chose to cache it within the RFC3484 policy tables, can we 
>>> change/augment the current syntax/format to accommodate that?
>> 
> The Linux Way of recent days seems to be to replace /etc/<software>.conf with 
> /etc/<software>.d/*.conf so in Linux specifically you could implement it like 
> this:
>
> /etc/gai.conf:
> And then your address selection policy update daemon(s) would update their 
> own file(s) in /etc/gai.d/ safely.
>

I think it much more complicated:
- You have default ruleset initialised by the operating system.
- You can  have host specific ruleset configured by the particular node 
configuration files - usually loaded by the startup process like 
from /etc/<software>.conf (or /etc/<software>.d/*.conf) into the kernel

- You might opt from loading something into the kernel from the previous 
cache. I don't think it is reliable. OS should send out something like 
confirmation, whether it is still valid or ICMPv6/DHCP policy table 
solicitation/request.

  - You can have a daemon process, that actually initate this policy table 
solicitation/request and process the incoming policy table and insert the 
ruleset into the kernel.

I don't believe that overriding a particular rule either from 
configuration file or any  policy table distibution method would be 
possible. Every operating system or local setup migth be different 
therefore complete table override is possible, but modifying one rule 
not....

Best Regards,
 		Janos Mohacsi

-

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 12 Jul 2010 17:57:14 +0900

Hi Alex,
thank you for comments.

If I understand it correctly, your comments are about implementation.
It's okay if we decide this merging issue is up to implementation.
But, we are still trying to fix a spec for merging.

Moreover, this time, we've almost decided to separate non-merging-capable
mechanism from merging-capable one. So, why not fix it first ?

On 2010/07/12, at 17:34, Aleksi Suhonen wrote:

> The Linux Way of recent days seems to be to replace /etc/<software>.conf with /etc/<software>.d/*.conf so in Linux specifically you could implement it like this:
> 
> /etc/gai.conf:
> And then your address selection policy update daemon(s) would update their own file(s) in /etc/gai.d/ safely.
> 
> I don't have a good understanding on how other operating systems have implemented RFC3484 so I can't comment how universal this would be.
> 
> -- 
> 	Aleksi Suhonen

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 12 Jul 2010 18:17:02 +0900

Hi,

I do not think it quite reasonable to leave much space between the rules, because the default rules can be cleared and overridden easily.

I agree with Alex in that the administrators tend to minimize the changes to the default rules. But it does mean to minimize the semantics changes, and not necessarily to minimize the lines of commands.

> Aren't we removing site local completely while we're at it? Or if it should be kept around, then why not add 3ffe::/16 too for the same reason?

as per RFC3879,

4.  Deprecation

   This document formally deprecates the IPv6 site-local unicast prefix
   defined in [
RFC3513
], i.e., 1111111011 binary or FEC0::/10.  The
   special behavior of this prefix MUST no longer be supported in new
   implementations.  The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action.  Future versions of the
   addressing architecture [
RFC3513
] will include this information.

   However, router implementations SHOULD be configured to prevent
   routing of this prefix by default.

   The references to site local addresses should be removed as soon as
   practical from the revision of the Default Address Selection for
   Internet Protocol version 6 [
RFC3484
], the revision of the Basic
   Socket Interface Extensions for IPv6 [
RFC3493
], and from the revision
   of the Internet Protocol Version 6 (IPv6) Addressing Architecture
   [
RFC3513
].  Incidental references to site local addresses should be
   removed from other IETF documents if and when they are updated.
   These documents include [RFC2772, 
RFC2894, RFC3082, RFC3111, RFC3142
,
   
RFC3177, and RFC3316
].

   Existing implementations and deployments MAY continue to use this
   prefix.

So, for the future use, we should not treat fec::/16 differently.
And for the time being, if we think about it may be used somewhere,
we should not treat fec::/16 differently.

And, it may be true for 3ffe::/16 also.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 12 Jul 2010 18:23:10 +0900

Hi,

On 2010/07/12, at 16:01, Mohacsi Janos wrote:

> I think 6to4 and teredo should be treated similarly - after ipv4. They should be used as a last resort acess to IPv6 resources. I think 6to4 should be kept since 6to4 is the most implemented IPv6 of the CPE equipments.
> 
> Best Regards,
> 		Janos Mohacsi

I agree.
It is clear to me that there is no longer preferences for 6to4 over IPv4, as well as preferences for Teredo over IPv4.

But, between 6to4 and Teredo, I tend to prefer 6to4.
Especially 6to4 host to 6to4 host communication is direct, there are some essential reasons to prioritize 6to4 over Teredo.

Regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 13 Jul 2010 04:47:13 +0900

Tim,

thank you for your generous efforts on this draft.
Now this document is quite thorough. I really appreciate it.

When we finish this document, why not bring this and go out to 6man ML for discussion ?

Several comments below.

 4.5. Multiple Interface Nodes
     ...
   not.  In this case it is interesting to note the choice to use the
   VPN tunnel for all, or just VPN home site traffic, is typically left
   as a choice for the user via a tickbox selection.

From my experience, even the tick-box does not appear. If I install and launch VPN software, it changes several related settings as it wants. I think this is quite reasonable behavior of VPN software. The software interprets that it is given highest priority from the user by installing and launching the software.

6.3.  Manual Configuration?

   There are scenarios where a host may wish to ignore conveyed policy.
   For example, the manager of a mobile node may not want to have its
   preferences changed by a visited network.  In such a case one might
   argue that the mobile node should use MIPv6 with whatever its home
   network policies are.

   The implication again is that there could be value in having a flag
   of some kind to inform a host whether network it is in uses the
   default RFC 3484 policy, which would then allow each end system to
   decide if it should get an (overriding) local policy or not.  One
   problem with this though is that some operating systems already
   implement 'modified' RFC 3484 behaviour, so we would have to be sure
   that all nodes have common understanding of what the 'default' is (in
   principle, that all nodes implement any future revised RFC 3484
   default policy table).

I think this whole point is rather related to the solution section. 
And especially in merging subsection. It is about policy merging or
non-merging of default policy table or manually configured policy
with the received policy.

6.4.  Policy Conflicts

Again, this whole point also should be placed in solution space ?
At least, it is not about when to obtain poicy.

7.2.  Pull model
...
   an administrator, is a more practical use of DHCPv6.  If future
   methods offer additional 'hints' based on routing information, this
   becomes part of the 'policy conflict' problem to be solved.

I do not know why hints based methods solve the policy conflict.
As far as the destination address selection based on precedence is used,
policy conflict can not be helped. In policy table based one, an entry
in the table can conflict with others, and in hinsts based one, a hint
can conflict with other hints. In my understanding, that's the only
difference.

7.3.  Push model
...
   However, we may
   find that RAs may be a good place to indicate whether a default
   policy is in place or not, to avoid hosts requesting non-existent
   updates via DHCPv6.

I think I fail to see the reason why the O flag of RA is not enough.

7.4.  Routing Hints
...
   The same thought seems relevant to address selection.  There's no
   point selecting a source address whose prefix is not being advertised
   in RAs.

   While routing and prefix hints may help a host make selection
   decisions, we should consider to what extent we wish to 'burden' a
   host with holding such information.  If a host is to determine and
   cache routing hints, this may require an update of RFC 3484 policy
   table syntax to support preference for address pairs.

In this section, what you suggest is to keep looking at RAs in order
to know upstream network changes ? I think it is more helpful is
it is described that way.

About the last sentence, I fail to guess what the routing hints are
like, and therefore why we many need to update policy table.

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Jul 2010 22:56:29 +0100

> Especially 6to4 host to 6to4 host communication is direct, there are some essential reasons to prioritize 6to4 over Teredo.

The problem with 6to4 is its inherent unreliability unless both communicating parties have ISPs that have 6to4 relays, and even then it can be problematic.    Yes, host to host is different, but it's hard to recognise that usage in a predefined policy table.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Jul 2010 23:33:29 +0100

> When we finish this document, why not bring this and go out to 6man ML for discussion ?

Yes,we should do that.

> From my experience, even the tick-box does not appear. If I install and launch VPN software, it changes several related settings as it wants. I think this is quite reasonable behavior of VPN softwa…

Comment added.

> At least, it is not about when to obtain poicy.

Agree.   Both moved.

> can conflict with other hints. In my understanding, that's the only

Sentence removed as it is ambiguous and unnecessary in the text there.

> I think I fail to see the reason why the O flag of RA is not enough.

OK.   Text removed.

> like, and therefore why we many need to update policy table.

Imagine an ICMPv6 query that could get an ordered list of address pairs as a response.    We do plan to write a draft based on the implementation we have done of that, just time has been an issue.

Tim

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 13 Jul 2010 11:18:55 -0700

They server different communities. The people that actually provide a
service would use 6rd, while people that want access despite their lethargic
local loop provider would use 6to4. The people that want to deprecate 6to4
want to force the world to be managed and keep the pesky users in their
place. 

Tony

> -----Original Message-----
> From: [email-masked] [mailto:addr-select-dt-
> [email-masked]] On Behalf Of Tim Chown
> Sent: Sunday, July 11, 2010 8:38 AM
> To: [email-masked]
> Subject: Re: [addr-select-dt] Proposed default policy table
> 
> Tony,
>

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 13 Jul 2010 11:27:52 -0700

I have no problem with leaving more space, I just didn't want to take people
too far from what existed... ;)

I don't believe we are actually deprecating 3ffe::, just operationally
removing it from use at this time. It was never defined with a specific
functionality in the stack, so it should not get downgraded unnecessarily.
Due to the explicit 2000::/3 not covering it, 3ffe:: will fall into
'default', so it does get a lower preference indirectly.

Tony

> [email-masked]] On Behalf Of Aleksi Suhonen
> Sent: Sunday, July 11, 2010 4:52 PM

---

From: Aleksi Suhonen <[email-masked]>
Date: Wed, 14 Jul 2010 08:05:40 +0000

> functionality in the stack, so it should not get downgraded unnecessarily.

OK.

> 'default', so it does get a lower preference indirectly.

Except that 2000::/3 does cover 3ffe::/16.

---

From: Tim Chown <[email-masked]>
Date: Wed, 14 Jul 2010 11:03:48 +0100

I think that just reinforces why different policies are needed in different scenarios.   Using 6to4 for an enterprise would be 'brave' while in SOHO networks the view may be different.   An OS vendor/implementor can't cater with default settings for both.

Tim