>>>>> On Thu, 28 Jul 2005 17:28:57 +0900,
>>>>> Arifumi Matsumoto <[EMAIL PROTECTED]> said:
>>> Case2: ULA or Global Prioritization
>>> Case3: Multicast Source Address Selection
>>
>> For these cases, using a non default policy table could resolve the
>> issue (and automatic policy distribution would help), but I personally
>> think this should be rather dealt with through a clarification for the
>> "default" selection rule, with the fact that site-local unicast
>> addresses were deprecated and ULAs are introduced.
> As you mention it, if ULA's address scope is defined like
> Scope(link-local) < Scope(ULA) < Scope(Global),
> the case 2 problem will be solved.
> As Stig has pointed out, however, defining an appropriate
> scope for ULA doesn't solve all the problems related to
> ULA site, which I described below.
(snip)
> As for this point, we've had a related dialogue just before
> the previous IETF meeting on dhcwg ML, which I paste below.
> A VPN connectivity and a native IPv6 connectivity environment
> can be an answer to the first question. That is, a site has a
> native IPv6 connectiviy and also has a VPN connection, over the
> native IPv6 line, to another site that doesn't provide transit
> connectivity to a VPN-connected site. In this case, the same
> problem occurs as the case 4.
> In addition to this, what we believe is that ASP services like video
> streaming, ip phone, security service and home appliance maintenance
> will be getting into home networks and this trend has already started
> to happen.
> Even if each of these ASPs uses ULA, address selection problem
> occurs once one of them has a peering with another site or
> once one of them acquires another ULA block.
My fundamental question here is why such closed networks need global
IPv6 addresses (or even any IPv6 addresses) in the first place.
Whether it's a VPN site or a closed ASP, doesn't it suffice to simply
use private IPv4 addresses? If I were a network administrator, who is
inherently conservative, I'd not take a risk of introducing
possibly-unstable/immatured IPv6 equipments for purposes in which I
don't need global connectivity.
Even if I were to choose to use IPv6 for some reason, it seems I'd be
just happy with ULAs for such purposes, and then the (revised) default
address selection algorithm seems to suffice (and so we don't need the
automatic configuration mechanism). I didn't understand why the
default algorithm doesn't work here after re-reading the past message
you attached and re-reading Stig's message. Perhaps I simply
misunderstood the point - so could you provide a concrete example
explaining why the default rule doesn't suffice there?
BTW: I'm not necessarily against the proposal per se. I was just not
convinced about the applicability of this mechanism *in practice*.
So, if a majority of this wg believes we don't need convincing
practical scenarios to adopt this proposal, I'll simply shut up.
But if others also want such evidence, what I'd seek is:
- realistic and convincing usage examples where the non default
address selection rule is necessary. depending on the answers to
the following points, I guess the VPN or closed ASP examples will
suffice.
- practical reasons why the closed network needs IPv6 to begin with.
I've not been convinced on this point yet at all.
- (on top of that) concrete examples showing why the (revised) default
address selection rule doesn't work if we use ULAs for the closed
network. (I'm probably seeking this just due to my
misunderstanding.)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
