Re: Your comment on the minutes for 6man@IETF71

[Arifumi Matsumoto <[e-mail]>]

Rémi,

thank you for clarification.

Regarding IPv4 private address scope issue, in [e-mail] ML,
it was discussed a lot recently and some people suggested to
make IPv4 private address scope global.

As you mentioned, I agree that application specific address
selection behavior should be implemented by using RFC 5014 or
its extension.

Anyway, these issues should be fixed by revising RFC 3484 itself
I believe.

Kindest regards,

Arifumi Matsumoto


On 2008/06/03, at 20:20, Rémi Denis-Courmont wrote:

>
> 	Hello,
>
> On Tuesday 03 June 2008 13:44:26 ext Ruri Hiromi wrote :
>> Hello, we are just reviewing the minutes for modification of our
>> draft(http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-sol-0
>> 0.txt ), we hope you taking your time for clarification of your  
>> comment.
>>
>> In the minutes, you said, "need?" in reply to Dave Thaler's comment  
>> as
>> "2 mechanisms, using scope or table - row in table is simpler how do
>> you get cfg out of the host without changing specs".
>> Could you give us more details about "need?"? Did you mean "Is  
>> there a
>> necessity for 2 mechanism?" ?
>
> Hmm, Philadelphia is far... If I recall correctly... I hinted that  
> we may need
> to make the scopes also a configurable policy table. In RFC3484,  
> precedences
> and labels are configurable, but not scopes.
>
> Because scoping rules are applied before any label or precedence  
> rules, there
> are scenarios where it is impossible to configure the source address
> selection policy.
>
> For instance, assume the sourcing host has:
> - SLL: one link-local IPv6 address,
> - S6: one public IPv6 address within the 6to4 label (2002:...), and
> - S4: one private IPv4 address from RFC1918 space.
>
> and the remote destination has:
> - D6: one public IPv6 address within the native label, and
> - D4: one public IPv4 address.
>
> Then the scopes are:
> SLL: link-local scope
> S4: private scope
> S6, S4 & D6: global scope
>
> No matter how you configure the label and precedence policy tables,  
> RFC3484
> will _always_ pick S6->D6, because it is the only couple with matching
> scopes. However, it seems realistic that S4->D4 would work better,  
> because S6
> is a 6to4 address, and 6to4 is not reliable. Of course, this a policy
> decision.
>
> One solution is to allow configuring the scope tables as well, but  
> it might be
> over-engineering, as this is quite static information. Another  
> solution is to
> add per-application "profiles" to the source address selection. As  
> such,
> applications that require network transparency would use the current  
> RFC3484
> scope tables and use S6->D6.
>
> But applications that do not need transparency and can work through  
> IPv4 NATs
> (such as HTTP) would use a different scope table where there all IPv4
> addresses are global scopes. In that case, you get, the scope  
> matching allows
> two different couples:
> S6->D6
> S4->D4
> Because S6 (6to4 label) and D6 (native label) have different labels,  
> and
> S4->D4 have the same label (IPv4 label), S4->D4 would be preferred.
>
> In practice, this could be implemented using a new source address  
> selection
> flag to the getaddrinfo() socket API, e.g. extending RFC5014.
>
> -- 
> Rémi Denis-Courmont

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------