Subject: revision of RFC3484

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 29 May 2006 19:23:36 +0900

Hi, all.

I'd like to start revision of RFC3484, because everybody knows
it has some defects and I think this issue of address selection
at end hosts is very important.

The points that I want to include in the revision of RFC3484
are follows:

Essential points,
* to remove site-local unicast address related statements.
  RFC3484 contains a few "site-local unicast" description.
  It's better to remove examples related to site-local
  unicast address, or change examples to use ULA.

* to update default rule.
  The default rule today is:
      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::/96                 20     3
      ::ffff:0:0/96         10     4

  What we should consider now is,
  - IPv4-compatible IPv6 address is deprecated.(RFC4291)
  - Teredo is defined. (RFC4380)
    Teredo should have less priority than 6to4 and IPv4
    considering its communication overhead and reliability ?
    Also, this value below conforms to Windows.
  - ULA should have less precedence than IPv4.
    As brought up by Pekka Savola, ULA is a possible cause
    of connection failure. It gets worse, as IPv6 deployment
    proceeds and more FQDNs have both A and AAAA records.

    As a few people already pointed out, I guess it's not
    so easy to solve the Pekka's ULA and IPv4 trouble other
    than to change policy table. While the problems caused
    by prioritizing ULA lower than IPv4 seem to be relatively
    easily solved. For example, by removing A record, using
    DNS zone-split, like that.

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::ffff:0:0/96         10     3
      fc00::/7               8     4
      2001::/32              5     5

Not essential but helpful,
* To add ULA related considerations if any.

  For example, we have to pay attention to source address
  selection for a multicast packet. By default, ULA will
  be chosen for a multicast packet of any scope.

* To define data type and length of each item in policy
   table hopefully.

  Though this issue maybe trivial, 
  if a site administrator wants to set some policies to 
  every hosts in his site and his site has every kind of
  operating systems, it causes difficulties for him to 
  determine the site-wide policies.

  Also it has bad effects even for normal users when they
  try to set-up the policies that are putted on a how-to
  web-page for another operating system.

  Though these aren't direct interoperability issues,
  these indirect interoperability issues seems not negligible.
 
* to add temporary address selection rule for policy table.

  As you know, temporary address has good and bad points.
  it's good to view web-pages or communicate with general public.
  it's bad for such a service that based on address based
  authentication.

  It's better if you can control on/off of temporary address.
  It's much better if you can control which address to use
  for which service. IMHO, Policy Table is the best place
  to implement this additional function.

      Prefix        Precedence Label  Temporary
      2001:db8:/16          40     1     off
      ::/0                  20     2      on
  
  In this simple case, you use temporary address for every site
  other than your corporate network(2001:db8::/16).

  You don't have to change the existing RFC3484 source
  address selection rules drastically, because temporary
  address related rules have less priority than policy table
  related rules.

Any comments are welcome.
Best regards,

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

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 29 May 2006 17:21:34 +0300

Hello,

>     Also, this value below conforms to Windows.

I pretty much agree that Teredo should have a lower priority than public 
IPv4 space, but it is not so obvious with regards to private or 
link-local IPv4 addresses... in the client to server case were NAT are 
a non-issue, using IPv4 is better anyway, but in other cases (e.g. SIP 
calls, p2p...), it will probably be worse.

>     DNS zone-split, like that.

As with Teredo, it should at least be safe to underprioritize ULAs 
against public IPv4 space, but if I understand correctly, that implies 
adding 4 extra IPv4 rules (3 for RFC1918, and one for 169.154/16). And, 
yeah, I can't think of any safe choice in between private IPv4 and 
ULAs.

>   to implement this additional function.

Similarly, it might (?) be nice to have a (IPv4) NAT-friendly 
application profile and a NAT-unfriendly one, though they might be 
caveats that I've not thought of.

-- 
Rémi Denis-Courmont

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 May 2006 21:29:15 +0200

> caveats that I've not thought of.

I think it's impossible to find defaults that fit all. We should have a 
sensible default, and I think some minor changes should be made, but IMO 
there may be many cases where this needs to be configured to match 
individual site preferences.

Stig

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 30 May 2006 15:42:36 +0900

Hi,
thank you for your reply.

Stig Venaas wrote:
>> I pretty much agree that Teredo should have a lower priority than 
>> public IPv4 space, but it is not so obvious with regards to private or 

In RFC3484 Section 3.2, scope for IPv4 is already defined
just like you said.
So, public IPv4 address has a higher priority, and
private or link-local IPv4 address has a lower priority
than Teredo, because of dst rule 2, if you use the
Policy Table I proposed.

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::ffff:0:0/96         10     3
      fc00::/7               8     4
      2001::/32              5     5

About SIP and P2P applications,
especially nowadays, they are already NAT-aware. So, it
doesn't cause big problem to treat a private IPv4 address
as a global address. How do you think about this ?

>> adding 4 extra IPv4 rules (3 for RFC1918, and one for 169.154/16). 
>> And, yeah, I can't think of any safe choice in between private IPv4 
>> and ULAs.

The same is true for ULA.

So, even when you use a private IPv4 address under NAT router,
ULA/Teredo will be chosen for www.kame.net(whcih has public A and AAAA)
because ULA and Teredo has global scope.

>> caveats that I've not thought of.

Yes, it sounds good if a host can detect NAT and use appropriate
address selection profile. But I guess the detection system will be
so complicated because the system has to be stateful and dynamic.

> individual site preferences.

Stig,

Yes, I absolutely agree that we cannot make perfect default rules.
But, at the same time, we should not leave a harmful default rule as it is.
We should make less harmful and more beneficial rules for more people.

After making the default rules and RFC up-to-date, I want to discuss
a mechanism to control/distribute site preferences.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 30 May 2006 20:32:57 +0300

Le Mardi 30 Mai 2006 09:42, Arifumi Matsumoto a écrit :
> especially nowadays, they are already NAT-aware.

They might be in a few years. They are definitely not yet, but OK, the 
updated spec is not there yet either.

> ULA/Teredo will be chosen for www.kame.net(whcih has public A and
> AAAA) because ULA and Teredo has global scope.

Ok, thanks for the clarification.

> so complicated because the system has to be stateful and dynamic.

I was actually thinking about selecting in the software rather than 
host-wide, such as through a new flag for 
getaddrinfo()'s “hints.ai_flags”.