Subject: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt

From: Alain Durand <[email-masked]>
Date: Fri, 13 Sep 2002 17:15:06 -0700

> o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source
>  address field, applications that assume basic API behavior will be
>  tricked to believe that the packet is from the node itself (IPv4
>  loopback address, 127.0.0.1).

How is that different from the case of an IPv4 application receiving
a packet with src address = 127.0.0.1?
The kernel should have dropped it before passing it to
the application.(see my last comment in this mail)

> o By transmitting IPv6 packet to firewall device, with IPv4 mapped
>  address corresponds to address inside the firewall (like
>  ::ffff:10.1.1.1) as the IPv6 source address, malicious party could
>  bypass IPv4 filtering rules and inject traffic inside the firewall.

This only means that ingress filtering should be smarter...
And anyway, with all the security issues concerning tunneling
and open relays, firewalls needs to be smarter.

> o Assume that the victim node is an IPv4/v6 dual stack node.  By
>  transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4
>  broadcast address (::ffff:10.255.255.255) in IPv6 source address
>  field, to TCP/UDP port that swaps IPv6 source and destination address
>  (e.g. UDP port 53, DNS), malicious node can trick the victim node to
>  generate improper IPv4 broadcast traffic; This is because basic API on
>  the victim node will emit transmission requests to destination IPv4
>  mapped address, ::ffff:10.255.255.255, into IPv4 traffic.

If a kernel implements 'basic API' semantic, it would/should
drop any packet which src/dst address is v4-mapped.
However, it the kernel implements 'SIIT' semantic,
and passes v6 packets to applications with IPv4-mapped src addresses,
the reserver is also ture, that is, when those applications will answer,
the kernel will output a v6 packet, not a v4 packet...
Then up to the SIIT box to drop directed broadcast.

	- Alain.

---

From: [email-masked]
Date: Sun, 15 Sep 2002 09:18:09 +0900

>the application.(see my last comment in this mail)

	not really different, but this is not obvious, from piles of IPv6
	documents, what kind of traffic people needs to filter it.

>and open relays, firewalls needs to be smarter.

	no, it is not just about firewalls.

>drop any packet which src/dst address is v4-mapped.

	where this recommendation is documented?  i believe nowhere.

---

From: Alain Durand <[email-masked]>
Date: Sat, 14 Sep 2002 20:22:52 -0700

> 	where this recommendation is documented?  i believe nowhere.

I think this is the core of the discussion. My take is that
it should be documented somewhere that if one one implements
basic API semantic, the kernel should drop incoming packets with
IPv4-mapped src address, but if one decides to accept them,
then when the same kernel is asked to send an IPv4-mapped
address, it should sent it on the wire as an IPv6 address.

The fist behavior is fine for dual stack host, the second
for IPv6-only hosts.

	- Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 16 Sep 2002 03:17:56 +0900

>The fist behavior is fine for dual stack host, the second

	for each host, the above story may make sense.  however, for a operator
	of a given site (like sun.com) there will be IPv4-only nodes, IPv6-only
	nodes (with SIIT support) and IPv4/v6 dual stack nodes.  if we are
	to add the above sentences somewhere and leave IPv4 mapped address
	on wire be legal, it will be unmanageable.

itojun

---

From: Alain Durand <[email-masked]>
Date: Sun, 15 Sep 2002 22:56:25 -0700

On Sunday, September 15, 2002, at 11:17 AM, Jun-ichiro itojun Hagino 

> 	on wire be legal, it will be unmanageable.

I do not see why it would add any extra unmanageable complexity.
The only place where extra caution would be needed would be
the firewalls, and those one anyway need to be rethink
to understand Ipv6 in Ipv4 tunnels better.

Actually, I think that a solution like this one (SIIT+NAT64)
would enable me to deploy an Ipv6 only island in my network
with reasonable chances to make it work
(that is, no worse than today's NAT)

	- Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 16 Sep 2002 23:19:48 +0900

>to understand Ipv6 in Ipv4 tunnels better.

	so tell me - assuming that there are mixture of IPv4/v6 dual stack
	nodes and IPv6-only nodes in your site.  when IPv4 traffic comes in to
	your firewall box, how a firewall can decide if it should let the
	traffic go through as is, or to translate it in SIIT way?

>(that is, no worse than today's NAT)

	SIIT/NAT64 are RSIP for IPv4 and IPv6 - end node knows what needs to
	be done at NAT box, and end node must act like IPv4 box (see RFC2765
	page 6 for very strange description - it asks IPv6-only node to compute
	IPv4 AH checksum).  i don't think they are workable even in IPv6-only
	cloud.

itojun

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 07:57:39 -0700

On Monday, September 16, 2002, at 07:19 AM, Jun-ichiro itojun Hagino 

> 	traffic go through as is, or to translate it in SIIT way?

If it is v4 traffic, the firewall applies v4 sanity checks.
The SIIT box does not need to be collocated with the
firewall.
Inbound packets that need translation (at least in NAT64)
have an IPv4 dst address of one of the NAT64/SIIT gateways.
They are easily identifiable by the firewalls if necessary.

\What is the problem?

> 	IPv4 AH checksum).  i don't think they are workable even in IPv6-only

SIIT/NAT64 is not RSIP. It does not negotiate anything with the NAT box
It is much more like plain IPv4 NAT. Same model. Things that work
today with IPv4 NAT still work with NAT64. Things that do not work
with IPv4 NAT (like IPsec) still do not work with NAT64.

NAT is not a perfect solution, but a solution that, like it or not,  
the Internet is now
very familiar with. We know the limits, and where it works, it works 
rather well.
This is because this model is well understood today that I think 
SIIT/NAT64
is workable.

Also remember, SIIT/NAT64 are designed as transition mechanisms, that is
don't expect them to solve all problems. What makes a transition 
mechanism
interesting is if it solves a large enough problem, is deployable and 
is simple
enough to understand.

	- Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 01:05:10 +0900

>What is the problem?

	so you assume every IPv6 site to have two IPv4 addresses, instead of 1?
	people wants to collocate their firewall and SIIT, to reduce IPv4
	address requirements.

>with IPv4 NAT (like IPsec) still do not work with NAT64.

	SIIT/NAT64 is RSIP.  a proof - SIIT/NAT64 FTP client has to know
	about how to deal with PORT/PASV command, even though they run on
	IPv6-only stack.  If the IPv6-only node only implements EPSV/EPRT
	(with IPv6 address support only), it won't be able to use FTP over
	SIIT/NAT64.  SIIT/NAT64 imposes very strange requirement to the end
	devices.

	normal NAT box, and good translators, does not impose any new
	requrirement to end clients.  NAT-PT and TRT requires no modification
	at all to IPv6-only (or IPv4/v6 dual stack) nodes in the cloud.

itojun

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Sep 2002 13:36:11 -0400

> the Internet is now very familiar with. We know the limits, and 
> where it works, it works rather well.

I strongly disagree.  Most network admins are still not familiar 
with the problems NAT causes. Most network admins still do not understand
the limits of NAT.  No general workarounds for NAT have been identified.  
NAT "works" only by drastically decreasing the flexibility of the Internet
to support new applications, so claims that it "works rather well" need
to be taken with a large dose of salt.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Sep 2002 13:36:56 -0400

normal NAT box, and good translators, does not impose any new
        requrirement to end clients.

that's completely false.

how can we make progress if people are still in this level of denial?

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Sep 2002 13:58:53 -0400

yeah, I know.  I shouldn't send such messages.  I offer my apologies.

for what it's worth, I interpreted "clients" as applications, not hosts.  
hosts may not be impacted by NATs.  apps certainly are, and I doubt that
itojun would claim otherwise.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Sep 2002 14:45:15 -0400

> Don't take me wrong, I'm not saying NAT is a perfect solution, far from
> that.  I'm saying the model is well understood, partly thanks to you Keith.
> We know where it works and where it does not. That knowledge
> may or may not have percolated to all network admin, but its
> a different issue.

well, given that I don't think I can come up with a concise statement
of where NAT works and where it does not, at least, not without lots
of wiggle room - I seriously doubt that "we" (for any larger set of
people) understand NATs well.  The midcom people have made progress,
but the ugliness of their partial solution should tell us something.

> I'm not advocating NAT instead of IPv6, I'm saying that NAT-like
> (NAT64/SIIT) technology would enable to deploy IPv6-only
> networks. Such hosts will work exactly the same as IPv4 hosts
> that are today behind a NAT when talking to the IPv4 world
> and benefit from end-to-end connectivity when talking to the IPv6 only
> world.

It's clear that some form of NAT is required to allow most apps on
IPv4-only hosts to exchange information with apps on IPv6-only hosts -
if only because it's impractical to build an ALG for each app.

> The success (or failure) of IPv6 will not be measured by how well
> early deployment using dual-stack technique will work, but
> by how well large to very large IPv6-only networks will operate.

and by whether those networks are more functional than NATted v4 networks.

the real challenge is for the transition mechanisms to avoid imposing
NAT-like restrictions on communications between application components
on v6-capable hosts.    otherwise, there's little point to IPv6.

actually, let me back up - the real challenge is for IPv6 (with or without
transition mechanisms) to avoid imposing NAT-like restrictions on 
communications between application components on v6-capable hosts.
Because current ideas about address selection, multihoming, renumbering,
and limited-scope addressing, actually impose many of those restrictions
even without considering transition mechanisms.
 
> One think that we learned in the last 2 years by studying DNS, SMTP,
> SIP & friends is that, in order to keep the Internet from fragmenting
> and being balkanized, nodes needs to access basic services regardless
> of the IP version they are using. 

actually I suspect we will end up with a network which supports both
heavily NATted v4 and v6 - some apps using v4, some apps using v6,
and some able to tolerate either.  the apps in the latter category
will consist of those that tolerate NAT and don't care how big their
addresses are (e.g. the web), and those apps that have built-in 
support for intermediaries (that can serve as v4<>v6 translators)
and a transparent way of locating them (e.g. email).  

IF we are successful, v6-only apps will be those that cannot tolerate 
NAT.  v4-only apps will be limited to legacy, probably local-only apps 
that cannot tolerate NAT and/or have wired-in assumptions about address size.

> I think bridging both world at the IP layer makes more sense than
> bridging them at upper layers, and NAT-like technology is a natural
> candidate for that purpose.

again, I see two risks with this:

- one is that we pretend that it's a general solution.
- the other is that such mechanisms interfere with interoperation
  between v6-only hosts.

Keith

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 10:59:22 +0900

>I'm not assuming that.
>Please read more carefully what I wrote.
>--> 'The SIIT box does not need to be collocated with the firewall.'
>It does not mean it can not.

	ok, then how do you make SIIT and firewall collocate on the same box?

>> IPv6-only stack.
>> If the IPv6-only node only implements EPSV/EPRT
>> at all to IPv6-only (or IPv4/v6 dual stack) nodes in the cloud
>I may be ignorant, then please educate me with a clear example
>how NAT64 is different from NAT-PT in that regard.
>
>An IPv6-only end node working in an NAT64 environement
>will have to inplement what you call SIIT kernel behavior,
>that's all. the 'peer' address will be an IPv6 address, the same way
>as NAT-PT. It just happend that this address is a v4-mapped address,
>but as it would be sent over the wire, I still see no difference with NAT-PT
>in that regard.

	no, the above description is incorrect.

	SIIT/NAT64 environment:
	For an FTP client on IPv6 only kernel (on the lefthand side of the
	diagram) to be able to contact and transfer files across SIIT box,
	the FTP client has to implement and understand IPv4 FTP commands,
	such as PORT and PASV.  this is not a normal requirement to IPv6-only
	FTP client.  IPv6-only FTP client normally implement EPSV/EPRT, for
	protocol #2 (IPv6) only, and that's all.  remember SIIT/NAT64 box will
	not rewrite the payload of packets.
	so, the FTP client knows about IPv4 (= outside world from the SIIT box).
	this is why i call SIIT/NAT64 similar to RSIP.

	NAT-PT environment:
	FTP client on IPv6 only kernel (or IPv6/v4 dual stack kernel) talks
	EPSV/EPRT, with protocol #2 (IPv6).  NAT-PT box will translate the
	content of the FTP control traffic into IPv4 ones (PORT/PASV).
	therefore, FTP client is seeing IPv6 peer from FTP protocol point
	of view.

itojun

SIIT/NAT64 environment

FTP client
========== AF_INET6 API
IPv6 only kernel		SIIT box	IPv4 FTP server
  |				 |   |		  |a.b.c.d
==+==============================+= =+============+==
	IPv6 traffic			IPv4 traffic
	(::ffff:a.b.c.d)

SIIT/NAT64 environment

FTP client
========== AF_INET6 API
IPv6 only/dualstack		NAT-PT box	IPv4 FTP server
  |				 |   |		  |a.b.c.d
==+==============================+= =+============+==
	IPv6 traffic			IPv4 traffic
	(to some fake address)

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 11:13:18 +0900

>	no, the above description is incorrect.

	2nd diagram is for NAT-PT, of course.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 11:33:17 +0900

>I think I now understand your problem.
>What you say is true if and only if the ftp client has internal
>knowledge that ::ffff:a.b.c.d is a special address that is in fact an 
>IPv4 address.
>That is, FTP looks at it in a sockaddr_in/AF_INET and not a 
>sockaddr_in6/ AF_INET6
>structure.

	the internal knowledge is vital for SIIT/NAT64 to work.  it is
	not avoidable.

>This does not have to be the case. Remove that knowledge from the 
>application/kernel
>and then you do not need anymore PORT/PASV.

	if you remove the knowledge, FTP client on IPv6-only machine cannot
	transfer files from/to IPv4 FTP server (since IPv4 FTP server does not
	understand EPSV/EPRT, with protocol #2).

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 11:53:02 +0900

>	the internal knowledge is vital for SIIT/NAT64 to work.  it is

	and it does not matter if you are using sockaddr_in/AF_INET, or
	sockaddr_in6/AF_INET6.  (normally I assume AF_INET socket is not
	available on IPv6-only systems, btw)

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 14:21:45 +0900

>Not if your FTP client is IPv6-only!!!

	bzzzt.  wrong.
	if your FTP client is IPv6-only, it will issue EPSV/EPRT with protocol
	#2.   FTP server on the other end is IPv4-only, which does not
	understand it.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 17 Sep 2002 15:29:30 +0900

back to the original topic - the fundamental issue i'm raising is
	that it is evil to make dual use of IPv4 mapped address.  we need
	to make it to have single meaning (RFC2553 one due to the deployed
	codebase), otherwise we get a lot of security issues like i have
	listed and alike.

itojun

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 09:42:20 -0700

I'm not assuming that.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 11:29:27 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>to be taken with a large dose of salt.

[I've changed the title of this thread, as the discussion is no longer
on Ipv4-mapped addresses]

Don't take me wrong, I'm not saying NAT is a perfect solution, far from 
that.
I'm saying the model is well understood, partly thanks to you Keith.
We know where it works and where it does not. That knowledge
may or may not have percolated to all network admin, but its
a different issue.

One think that we learned in the last 2 years by studying DNS, SMTP,
SIP & friends is that, in order to keep the Internet from fragmenting
and being balkanized, nodes needs to access basic services regardless
of the IP version they are using. The current operational approach is
to mandate dual stack in the core infrastructure pieces of the Internet:
SMTP relays, DNS resolvers/servers,...
This approach works well in the early days, when the 'penetration rate'
of IPv6 is low (say < 10%) and will not be an issue when this
rate will be 80% or more (access to v4 services will not be critical 
anymore)
but I'm concerned that this will not work very well when
IPv6 penetration rate will be something like 50% and large to
very large IPv6-only network will be a reality.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Sep 2002 10:41:47 +0200

Alain Durand wrote:
...
> bridging them at upper layers,

I disagree with this generalisation. There are scenarios where
this may be true, but there are others where application level
proxies or edge servers may make more sense.

The 6net project is exploring both of these approaches. It's 
too soon to draw conclusions, but I hope we will get enough
experience with both to learn which scenarios make sense.

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 17 Sep 2002 15:06:50 +0200 (CEST)

I suspect the root of this argument is whether NAT as we know it
in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough".
If so NAT-PT is what we need.

Or do we want to improve on that?
For instance, do we want improvements that allows one to take advantage
DNSSEC through the NAT? 

Until we agree of the right approach or approaches at that level
I think the detail discussion is rather pointless.

> 	SIIT/NAT64.  SIIT/NAT64 imposes very strange requirement to the end

FWIW RSIP has a lot of other implications as it comes to port number allocation
and SPI allocation in the stacks.

The assumptions behind SIIT is that the node is dual stack (the protocols
as well as the applications) but the node  doesn't have a permanent IPv4
address and the local network infrastructure does not support IPv4.
With those assumptions there aren't any strange requirements on the devices
(ignoring the AH suggestion in the RFC:-); the ftp implementation on a 
dual stack node already needs to support old stuff when communicating with
IPv4 addresses.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Sep 2002 10:39:19 -0400

> If so NAT-PT is what we need.

that begs the question "good enough for what?"

> For instance, do we want improvements that allows one to take advantage

I propose three guidelines:

1. communication between v6-capable nodes MUST NOT use NAT, so 
   applications that do not tolerate NAT can use v6.

2. views of DNS MUST be kept consistent between v4 and v6, except 
   possibly for limited portions of the net for which some DNS ALG 
   is necessary, and even then we need to discourage it.

   in other words, don't use NAT as an excuse to pollute DNS.

3. if it is necessary/desirable to extend the flexibility of
   communication between v4 and v6 hosts (v4-v6 NAT) this should
   patterned after mechanisms developed for v4-v4 NAT.  this will
   minimize impact on software written to take advantage of
   v4-v4 NAT workarounds.  

   in other words, NAT is a disaster, and attempts to solve the 
   problem (DNSALG, RSIP, MIDCOM) should be sufficient evidence
   that there are no good solutions.   let's keep v6ops out of the 
   business of generating more bad solutions.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 00:26:46 +0900

(since this is transition tool discussion replies to ngtrans please)

>dual stack node already needs to support old stuff when communicating with

	if the above assumption is true, what do you intend to do about the
	dual use of IPv4 mapped address?  telnet client on dual stack machine
	would make a send(2) request to ::ffff:a.b.c.d, which will be captured
	by an AF_INET6 socket, and goes out of the node as IPv4 packet.
	there's no documented way in which ::ffff:a.b.c.d would go out as IPv6
	packet.  either RFC2553 API does not work, or SIIT dose not work.

itojun

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 17 Sep 2002 17:02:13 +0200

> This is because this model is well understood today that I think 

If NAT works so well in the first place, why do we then need IPv6 at 
all?

- kurtis -

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Sep 2002 18:50:58 +0000

> If NAT works so well in the first place, why do we then need IPv6 at all?

i expect that question to come up quite a lot, as part of the business case
analysis.  "i've got 20,000 ip-speaking devices, but only 7 of them have
universally unique addresses, the rest are in private address space because
i was not able to get a class B.  if i move to ipv6 i can get my own /48 but
it will be in my isp's address space, which will make multihoming hard and
make switching providers even harder.  do i really want to have to renumber,
even with ipv6's extensive automated assistance for this, whenever there's
a rate war at my local transit exchange?"  and then will come the question
you gave above.

(i'm done grousing about A6 -- that's a dead issue as far as i'm concerned.
but the problems A6 was supposed to solve or avoid didn't die with it, and
we're going to have to grapple with the business case analysis every step
of the way to full ipv6 deployment.  unfortunately, the early adopters are
all organizations of the kind who get their address space from RIR's rather
than from their upstream ISP's, so this issue hasn't yet seemed real here.)

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 19:23:07 -0700

- Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 16 Sep 2002 22:16:45 -0700

On Monday, September 16, 2002, at 07:33 PM, Jun-ichiro itojun Hagino 

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 17 Sep 2002 11:11:00 -0700

>I think the detail discussion is rather pointless.
I agree Itojun & I went a bit too far in the details of NAT64.
This was just to illustrate the point that IPv4-mapped addresses
can be used on the wire.

Now, to up-level the NAT discussion, the question IMHO is not
so much to ask if NAT as we know it in v4 is good enough or not,
but to really understand how v4 and v6 interoperate,
not in the early days of transition where IPv6 only exists
is some leaf sites, but when both IPv4 and IPv6 represent
a large portion of the entire Internet.

A few points:

a) The Internet is one. (RFC2826). In particular, the DNS name space is 
the same
     for both v4 and v6.
b) There will be a point where IPv6-only devices will show up.
c) There will be a point where IPv6-only networks will show up.

The current thinking for a) and b) is to heavily use dual-stack
in the infrastructure. (DNS resolver/server, SMTP relays,...)
Does this approach still makes sense for c) ?

Or another way to put it, when IPv6 penetration is < 10%,
inter-operability with IPv4 is critical, dual-stack on the
infrastructure is an acceptable price. When IPv6 penetration
is > 80%, such inter-operability may not be as important any more
But what should happen in the 20-70% range?

There are several approaches:

1) keep dual-stacking the infrastructure until the end of the times.

2) put ALGs at the boundaries of v4 and v6.
    Btw, who remember the days in Sendmail where there
    were 'well known' Bitnet and UUCP relays?
    Personal opinion, not sure I want to go there...

3) explore IP layer bridging.
    If we go that route, we can argue to see if IPv4 NAT is a
    good enough model or not, revisit NAT-PT, explore NAT64
    or invent something different.

So maybe the first question to ask is whether ot not looking
at the coexistence of IPv4 and IPv6 in this middle
phase of transition (20-70%) is part of the v6Ops charter or not.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 17 Sep 2002 11:16:33 -0700

> If NAT works so well in the first place, why do we then need IPv6 at all? 

Don't ge me wrong, NAT does not work very well. We still need v6.
Bridging IPv4 and IPv6 is a temporary/transition solution.
So the idea is:
- use v6, you'll have end to end connectivity between v6 nodes.
- but you still want to maintain some level of interoperability
   with v4, but don't expect miracles there.
   NAT is not a very good answer, but it is the best we have so far.

    - Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 05:33:13 +0900

>than from their upstream ISP's, so this issue hasn't yet seemed real here.)

	i have renumbered my home (/48) more than a couple of times without
	any problem.  yes, it may not extend naturally to enterprise network 
	where # of nodes are 10^4, but anyway,
	- IPv6 address autoconfiguration
	- multiple IPv6 address per interface
	- source/destination address selection
	makes renumbering so much easier than IPv4 case.  you just need to be
	careful about DNS TTL and RA address/prefix lifetime.

itojun

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Sep 2002 20:45:10 +0000

> 	careful about DNS TTL and RA address/prefix lifetime.

there's no question that it's easier than the ipv4 case.  congrats are
in order on that point.

however, at size 10**4 and above, renumbering of this kind will be 
expensive.  and at size 10**5 and above, it will be constant/overlapping.

my point was, that's a big reason why folks will ask "why not just use NAT?"

now i'm thinking, please don't make NAT any harder than it already is.

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Sep 2002 16:54:51 +0700

Date:        Tue, 17 Sep 2002 20:45:10 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | however, at size 10**4 and above, renumbering of this kind will be 
  | expensive.

The actual renumbering need not be expensive.  At the minute it would be,
but more tools/protocols can be developed to make the kind of renumbering
we're talking about more or less invisible as far as the site is
concerned (and yes, A6 would certainly have helped).

We're nowhere near there yet, but we can get there - that is, make all of
this possible.   That isn't to require anyone to actually use this stuff
if they don't trust it (the "I won't let anything reconfigure my router
except for me" attitude).

The other kind of renumbering (changing the internal structure of a net)
will perhaps still be hard (though not as hard as for v4) - but running
NAT doesn't help with this at all.

Actually producing something that uses site local addressing where possible,
to isolate local communications from the effects of a global prefix change
is another thing that will assist with all of this, just as external
renumbering is hidden by the use of 1918 addresses hidden behind a NAT.
I have some students working on this now - they seem to have it all working
in a prototype environment (to the stage where if you say
	telnet 3ffe:...
it actually makes a connection (where possible) to fec0:... instead)
That is, of course, going too far - if someone gives a numeric address,
that's what should be used, but this makes it easier for their testing,
as they don't get to own the DNS zone files, and so can't get their
systems included easily, so they're currently just using numbers.  The
current implementation isn't suitable for use in the wild, but it does
demonstrate that the method works, and site local addresses can be used
without anyone needing to know a lot about it (the application obviously
knows, and should be able to say "no", but most simply don't care).

  | and at size 10**5 and above, it will be constant/overlapping.

Huh?  What does the size of the net have to do with the frequency of
renumbering - if anything, smaller nets are the ones that tend to shift
around more frequently (they don't have the clout to get good deals from
providers initially, nor do they usually engage in longer term agreements
to achieve that - bigger places do).

If implemented rationally, there's no reason that renumbering a large net
should take a lot longer than a small one - that would only be the case
if we started needing a lot of human intervention everywhere.  That's
something that we need to get away from (and that includes getting literal
addresses out of filters and such, and instead using "my prefix" and then
the rest of the address, where that's what we mean).

  | my point was, that's a big reason why folks will ask "why not just use NAT?"

And the answer will be, that NAT achieves nothing, but does limit
applications, some things just don't work.   And once we get into an
environment where the default isn't "everyone uses NAT", more of the
kinds of applications that just don't work with NAT are likely to appear
(there will be no reason for them not to).

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Sep 2002 21:21:22 +0000

> concerned (and yes, A6 would certainly have helped).

A6 was a concrete solution, with plusses and minuses, and is dead now.

Alternatives which would also make renumbering less expensive are just
vaporware at the moment, and since I can't evaluate them I can't accept
your assertion that actual renumbering need not be expensive.

> to achieve that - bigger places do).

Larger networks are less mobile only when renumbering makes it so.  If you
take away the renumbering penality (for example, if you use NAT) then I'd
expect any network who attends a transit exchange such as PAIX or Equinix
to change their provider at least once a month during fee wars.

> | ..., that's a big reason why folks will ask "why not just use NAT?"
> 

What odds are you giving and how much are you putting up?

Please don't misunderstand my intent here.  I'm not using NAT and ISC is 99%
done rolling out IPv6 internally and I'm not trying to get anybody to feel
bad or act different concerning renumbering technologies, A6 or otherwise.

However, at the moment my take on all this is that folks are likely to use
more NAT rather than less.  Any application author who wants to make their
work NAT-unfriendly can't be -- and shouldn't be -- stopped.  But as far as
the core protocols go, I think we should do a better job avoiding moralism
tham IPsec did.  ("L4 routing/switching/firewalling is evil, so let's cover
the port numbers under the encryption envelope.")

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Sep 2002 17:58:20 -0400

> Any application author who wants to make their
> tham IPsec did.

well, let's be clear here.  the argument about NAT isn't a moral argument.  
it's about the flexibility of the network to support a variety of 
applications, reliability, network management, and user support issues.  if 
it looks like a moral argument to some people it's just because the deeper 
technical and economic issues are not immediately obvious to everyone.

it's hard to imagine that any authors "want" to make their work NAT-unfriendly.
however for some applications there are not good, or even feasible, 
alternatives within the current internet architecture, and it's very difficult 
to retro-fit the current architecture to provide such alternatives.
(see draft-moore-nat-tolerance-recommendations-00.txt)

just because NAT shifts some burdens from network operators to applications 
implementors, doesn't mean that it actually solves any problems - it just
moves the problems to a group of people who are fundamentally less able 
to solve them.

btw, I'm fully in agreement that people will use NATv6 or simply avoid v6
if we don't make renumbering fairly painless.  and we really need *some* WG 
to seriously tackle that problem.  perhaps this is the one?

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Sep 2002 11:01:27 +0200

below...

> to seriously tackle that problem.  perhaps this is the one?

Perhaps, but the real point is that with AAAA records, the main need
is for tools not standards - specifically, tools to perform bulk updates
of a site's DNS table. Many sites and enterprises have such tools already
and adapting them to IPv6 is straightforward enough, but sites that
don't have such a tool (and therefore probably don't have an organized
host database or even an organized host naming strategy) will find
IPv6 renumbering almost as obnoxious as IPv4 renumbering. 

This matters. Paul is being pragmatic, but if the NAT fungus infects
IPv6 deployment we will have painted IPv6 into a corner.

So, still being pragmatic, how can we stimulate the creation of
renumbering tools (especially DNS bulk renumbering tools)?

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Sep 2002 10:40:55 -0400

> renumbering tools (especially DNS bulk renumbering tools)?

IMHO, there is a need for both tools and guidance, and perhaps also
for minor protocol tweaks.  this was true even with A6 records.

if someone were to write a "how to renumber your network" document,
with appropriate consideration for all of the components of the 
network that might need to be tweaked (incl. routers, firewalls,
software that is configured to allow access only from local IP
addresses) and also consideration for what it takes to keep software
from breaking during the switch-over (listing different phases 
and recommending times for each) the exercise of writing this document
might also serve to identify any missing bits of protocol and missing
tools. perhaps I've missed it, but I don't think I've ever seen 
anything like a complete story on how to renumber a large network -
and until we have that, how can we be sure that the necessary pieces 
are all in place? 

Keith

---

From: Bill Owens <[email-masked]>
Date: Thu, 19 Sep 2002 16:27:33 -0400

At 17:58 -0400 9/18/02, Keith Moore wrote:
>if we don't make renumbering

. . . and multihoming . . .

>fairly painless.

Bill.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Sep 2002 11:11:27 +0200 (CEST)

> 	(since this is transition tool discussion replies to ngtrans please)

I thought the topic of the discussion was draft-itojun-v6ops
which the author seems to think belongs in v6ops :-)

> 	packet.  either RFC2553 API does not work, or SIIT dose not work.

An implementation needs to be configured to either be IPv6-only or
dual stack.
In the dual stack case the mapped addresses at the API correspond
to IPv4 packets on the wire.
In the IPv6-only case the mapped addresses at the API correspond
to IPv6 packets on the wire next to the node, and on the other side of
the translator they correspond to IPv4 packets.

What part of section 3.7 in RFC 2553 conflicts with this?
That section doesn't say that IPv4 packets are sent, it says that the
address is used to for IPv6 applications to interoperate with IPv4
applications. 

What part of the SIIT spec conflicts with RFC 2553?

Please be specific.

  Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 20 Sep 2002 19:37:04 -0500

"A6 was a concrete solution, with plusses and minuses, and is dead now."

A6 can not be dead, it is the heart and soul of IPv6. Without A6, how can there be an IPv6 ?

AAAA is for use with IPv4++. New versions of Windows produce IPv4 packets when sent 2002: model year addresses.

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved ("Spare") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.netfilter.org/
http://www.analogx.com/contents/dnsdig.htm
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 22 Sep 2002 22:02:12 +0200

> a rate war at my local transit exchange?"  and then will come the 

I have long been arguing that there is nothing I can do in IPv6 that I 
can't do in IPv4. It might be done in different ways, or in some ways 
easier, but it can still be done (in my opinion cleaner and easier in a 
lot of cases in IPv4). Still, I don't see another path ahead than IPv6 
at the moment, although I will be the first to point out the problems 
that IPv6 won't solve. I do think that we should go ahead, becuase if 
nothing else it will help us understand the real problems of migration 
and the problems with IPv4/IPv6 better.

This said, I think we have had enough of IPv6 "priest" and now need to 
get more operationally focused people in to the v6 discussions. Here 
Paul points out a interesting thing, so far we have seen the early 
adopters. I think they are generally keener to ignore potential 
problems for downstreams than then downstreams them selves - for 
obvious reasons. In away I think we are back to pre-CIDR - which have 
it's advantages and disadvantages. Keeping the number of routes down 
should be a priority concern in my opinon. Then again - I wan't to see 
the first first +100k employee organization renumber.

Best regards,

- kurtis -