On Tue, 2 Aug 2005, JINMEI Tatuya / [ISO-2022-JP] żŔĚŔĂŁşČ wrote:
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.
Currently we are facing an interesting problem that might justify the need
for this:
We have closed network that is using private IPv4 address. We are
expanding this network, but we run out of adjacent IPv4 addresses. We can
decide:
- renumber our closed network with other private IPv4 address space
- introduce IPv6 addresses.
Currently we are discussing internally the trade-offs the two options.
So we are not starting with IPv6, but considering replacing IPv4 are least
partially.
What do you think of it?
Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
- (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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
