Subject: Re: Proposed IPv6 W.G. Agenda for Paris

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 02 Aug 2005 18:30:07 +0900

>>>>> On Thu, 28 Jul 2005 17:28:57 +0900, 
>>>>> Arifumi Matsumoto <[email-masked]> 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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Tue, 2 Aug 2005 11:52:42 +0200

On Tue, Aug 02, 2005 at 06:30:07PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
[...]
> explaining why the default rule doesn't suffice there?

My point is perhaps not that important, but here's what I was thinking of.
Assume you are two sites are connecting to the global internet, both using
ULAs with a ULA peering between them.

Now, if a host is one of these sites do a DNS lookup for a host in the
other site, and get both a ULA address and a "normal" global address, you
will probably want to prefer both source and destination ULA addresses.

However, if a host in one of these sites do a DNS lookup for some random
host on the global internet and for some reason gets both ULA and "normal"
global address, it should prefer the "normal" one.

It might be discussed how important the latter is. The connection attempt
would hopefully fail quickly. Also sites are not supposed to leak ULAs
(should use split-DNS probably), this is almost bound to happen. Perhaps
it's good not to require split-DNS?

I have another point regarding ULAs and multicast. As discussed earlier,
there is a problem with longest common prefix match prefering ULA source
address for multicast. We've discussed a change saying that the "normal"
global address should be prefered for global multicast. I believe for
many sites using ULAs it would be natural to use ULA source address for
scopes <= 5, but there are other sites where it would be natural for <= 8.
With ULA peerings between different organizations and sites, it is possible
that some may want ULA source for say scope <= A, while "normal" global
addresses for larger scopes.

What I'm trying to say is that the part of the network that uses ULA and
have ULA peerings may not map to the same multicast scope in all
deployments.

Stig

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Tue, 02 Aug 2005 19:23:11 +0900 (JST)

Jinmei-san,

 | > 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.

There may be some reasons to use global IPv6 address in closed
networks. The reasons are: there will be some possibilities to connect
multiple 'closed' networks with each other, to have private connection
with other gloabl IPv6 network, to avoid confliction with users ULA
address, and so on.

And acutually, Registries allow to use gloabl IPv6 address in closed
networks, and some organizations got IPv6 gloabl address and have been
using them in their closed network.

So, "case 4, global and closed mixed conectivity"
(http://www.nttv6.net/dass/#content_1_17) is not the artificial case,
but the case we've been facing now. And I believe these kind of
connectivities will increase as IPv6 deployment progresses.

--
Tomohiro Fujisaki

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 2 Aug 2005 19:22:09 +0900

Jinmei-san, thanks for your comments.

Some replies below.

>   I've not been convinced on this point yet at all.

Do you recommend to use IPv4 addresses forever ?
IPv4 private addresses has another kind of problem even
for closed network, such as address collision.
I guess its very common to use private address in home
network, so its very likely to collide ASP's private address
and that in home network.

Another point is that when you start a new network service,
you want to use long-life technologies and not dying ones.

>   network.  (I'm probably seeking this just due to my

In my last e-mail, I meant that when one ASP uses more than
one ULAs or has peering with another ASP(which has ULA), a
consumer site cannot choose a correct source address by
default address selection rule.
This looks like the following.

+---+ULA1
|ASP|
+---+
  |
  | ULA2   ULA3
+---+ +---+
|ASP| |ASP|
+---+ +---+
  |     |
 ---------
     |
   +---+
   |GW |
   +---+
     |
-----------
        |
      +---+
      | PC|
      +---+

As ULA is such a small address space(/48), it is very probable
that an ASP has multiple ULA blocks.

Additionally,
at v6ops session yesterday, 6net people showed us another
possible usage of address selection policy table. It's renumbering.
By pouring address selection policy into each end hosts,
you can easily configure address selection policy that
makes end-hosts not to use old address.

--
Arifumi Matsumoto <[email-masked]>
  Ubiquitous Computing Project
  NTT Information Sharing Platform Laboratories
  TEL: +81-422-59-3334 / FAX: +81-422-59-5652

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 2 Aug 2005 12:26:56 +0200 (CEST)

>  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

---

From: [email-masked]
Date: Tue, 2 Aug 2005 14:09:39 +0100

In the course of doing the security overview draft in v6ops, we identified a
number of issues that appear to be errata or issues with the main IPv6 standard.
 These should potentially be fixed up as 2460 goes to full standard:

Points for full standard;
•	(non-)Processing of Type 0 routing headers in hosts
•	(non-)Processing of Type 2 routing headers in routers
•	Processing Extension Headers in Middleboxes - 
   o	words about where headers are inpected need to be relaxed
   o	words about processing headers out of order need to be relaxed
   o	should intermediate nodes be allowed to discard packets with unknown 
        extension headers?
•	Requiring that new extension headers use TLV format (and maybe putting the
length into the fragmentation header) - to simplify skipping headers in middleboxes
•	Constraining new hop-by-hop options both as to number and function - h-by-h
should be designed either for simple fast path processing (like jumbo packets)
or to explicitly cause a packet to be dumped to the slow path (like router alert).
•	Fragment reassembly algorithm - should explicitly forbid overlapped fragments
and possibly require that non-final fragments are (say) at least 1024 bytes.  

Regards,
Elwyn

Quoting Bob Hinden <[email-masked]>:

> Here is the first cut at an agenda for the IPv6 working group session at 
> the Paris IETF.  Please review and send us comments, deletions, and
> additions.
> 
> Thanks,
> Bob Hinden & Brian Haberman
> IPv6 Chairs
> 
> 
> Internet Protocol Version 6 WG (IPv6)
> Tuesday, August 2, 2005
> 1400-1600 Afternoon Session I
> --------------------------------------
> 
> Introduction, Call for Scribes,         Hinden          05 minutes
> and Agenda Bashing
> 
> Document Status                         Haberman        05 minutes
> 
> IPv6 Node Information Queries           Haberman	10 minutes
>    Goal: Close open issues
>    draft-ietf-ipngwg-icmp-name-lookups-12.txt
> 
> IPv6 Address Allocation to End Sites    Narten          20 minutes
>    Goal: Discussion
>    draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> IPv6 over IEEE802.16                    Kim		10 minutes
>    Goal: New draft, Initial Discussion
>    draft-jin-ipv6-over-ieee802.16-00.txt
> 
> URI Syntax                              Fenner          15 minutes
>    Goal: Make decision to adopt proposal
>    draft-fenner-literal-zone-01.txt
> 
> Implementation Reports for              Haberman        10 minutes
> Privacy Extensions for Stateless Address
> Autoconfiguration in IPv6
>    Goal: Call for reports
> 
> Next Steps for IPv6 w.g.                Hinden          15 minutes
> Advancing core specification to Standard
>    Goal: Discussion
> 
> 
> 
> 

--

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2005 16:23:31 +0100

> makes end-hosts not to use old address.

There were two 'interesting' states during the renumbering we did.

1) Both prefixes equally valid.  Here the address selection was somewhat
   'arbitary' on the four OSes we tested.  In reality this didn't matter
   too much, but it might be nice to have a policy distribution method
   indicate a shift to prefer the new prefix before deprecating the old 
   one.

2) Old prefix deprecated.  In this case the four OSes all selected
   addresses correctly, i.e. preferred active over deprecated addresses.
   This allows the Baker process to basically work, at least for the
   host configuration aspect.

As an aside, the undesirable property we observed after the deprecated
address became invalid (removed) was that applications and tools continued
to use that address as a source, but would never see replies.   One assumes
the address validity is only checked at bind time.  But that raises the
issue of how often the distributed policy is rechecked by the
system or applications.

Tim