Rémi, thank you for clarification.
Regarding IPv4 private address scope issue, in [EMAIL PROTECTED] 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------