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

[Arifumi Matsumoto <[e-mail]>]

Hi,

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

> 
> 
> 
> On Sun, 11 Jul 2010, Tim Chown wrote:
> 
>> 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.
> 
> 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,

> 
> 
>> 
>> Tim
>> 
>> On 8 Jul 2010, at 18:08, Tony Hain wrote:
>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> addr-select-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
> _______________________________________________
> addr-select-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/addr-select-dt


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