Subject: Re: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 18 Sep 2002 09:27:45 +0900

>does it matter?  siit box could be Ipv6 host.

	i think it does matter, but i leave more analysis to erik...

itojun

---

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

> 	i think it does matter, but i leave more analysis to erik...

Analysis of what?

AFAIK SIIT and RFC2553 work well together.

What is the problem?

  Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 21 Sep 2002 06:44:17 +0900

>AFAIK SIIT and RFC2553 work well together.

	if you have a node with:
	- dual stack support (kernel code supports IPv4 and IPv6)
	- RFC2553 with section 3.7 support (IPv4 mapped address)
	the node won't be able to interoperate with SIIT translator box.

	Let's say:
	- the node described above is A
	- SIIT translator is S
	- (IPv4) peer is X

	when incoming traffic from X via S reaches A, it will have IPv4 mapped
	address on source address field of IPv6 header.  it will get delivered
	to userland application on A (*), and getpeername(2) will return IPv4
	mapped address.  if the userland application try to respond to this
	(A -> S -> X), it will try sendto(2) against IPv4 mapped address,
	or TCP layer takes care of it.  since the destination address is IPv4
	mapped address, RFC2553 section 3.7 kicks in, and the traffic will
	go out of A as an IPv4 packet.

	(*) at this point, since IPv4 mapped address has dual use, I would
	recommend rejecting the traffic to avoid abuses documented in
	draft-itojun-v6ops-v4mapped-harmful-00.txt.  if you follow this
	recommendation, A won't interoperate with S anyways.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 15:29:51 +0200 (CEST)

> 	the node won't be able to interoperate with SIIT translator box.

If it is dual stack (including having IPv4 address(es) assigned to it)
it doesn't need SIIT hence any SIIT support in the box would presumably be
disabled.

> 	go out of A as an IPv4 packet.

That isn't how I would configure a network containing SIIT and dual-stack
nodes.
Instead I'd assign an IPv4 address pool for SIIT which is separate from
the IPv4 addresses assigned to the dual-stack nodes.
The routes for the first set IPv4 addresses would point at the SIIT box(es).
And routes for the dual-stack IPv4 addresses would point all the way
to the links inside the site.
Thus the SIIT box would only translate packets sent to the IPv6-only nodes.

Since the SIIT RFC doesn't specify a complete solution (address assignment
is out of scope) but merely the translation rules for the headers, it doesn't
cover this type of material. That doesn't mean the specification is
broken as you seem to believe; it means that there are other pieces needed
to make a complete solution.

Note that if you misconfigure things the way to propose the dual-stack
host would reject the packets since their destination address would
be an IPv4-translatable IPv6 address and the dual-stack host would not
have such an address configured; only IPv6-only nodes that use SIIT would.

So the problem isn't where you think it is.

  Erik

> 	recommendation, A won't interoperate with S anyways.

You appear to have found a problem in

---

From: [email-masked]
Date: Mon, 23 Sep 2002 22:37:34 +0900

>it doesn't need SIIT hence any SIIT support in the box would presumably be

	i'm a bit confused.  you have been saying that "dual stack nodes can
	work fine in SIIT cloud".  what did you exactly mean when you said
	"dual stack node" in the sentence?

	my assumption during the discussion (of dual stack node in SIIT cloud):
	even if the node is dual stack (IPv4 and IPv6 kernel support), it can
	have no IPv4 address assigned.  in such case, the node will want to
	use SIIT translator to talk with IPv4 nodes.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Sep 2002 16:01:18 +0200 (CEST)

> 	"dual stack node" in the sentence?

Nodes with the dual stack software and that software being enabled by having
one or more IPv4 addresses assigned.
	
> 	use SIIT translator to talk with IPv4 nodes.

My assumption is the opposite - a dual-stack node for the purposes of this
discussion has IPv4 address(es) assigned.

If a dual-stack node has no IPv4 address assigned you can treat it as
a IPv6-only node; it just has some unused IPv4 code in the kernel.

   Erik

---

From: [email-masked]
Date: Mon, 23 Sep 2002 23:07:29 +0900

>a IPv6-only node; it just has some unused IPv4 code in the kernel.

	for the RFC2553 API part, you can't treat the node as IPv6-only node.
	which is the real cause of the problem i have been trying to describe.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Sep 2002 11:53:21 +0200 (CEST)

> 	which is the real cause of the problem i have been trying to describe.

I completely fail to see the problem.

RFC 2553 doesn't say whether IPv4 or IPv6 packets are sent; it merely
says that IPv4-mapped addresses are used at the API to communicate
with IPv4 nodes using AF_INET6 sockets.
So as far as I can tell, whether the node itself is due stack and
emits IPv4 packets, or the node is IPv6-only and is using SIIT so
that IPv4 packets appear at the other end of the SIIT translator,
it has no effect on the API.

What am I missing?

    Erik

---

From: [email-masked]
Date: Tue, 24 Sep 2002 19:01:45 +0900

>emits IPv4 packets, or the node is IPv6-only and is using SIIT so	<-
>that IPv4 packets appear at the other end of the SIIT translator,	<-

	from my understanding, if you sendto(::ffff:x.y.z.u),
	- on IPv6-only node, an IPv6 packet to ::ffff:x.y.z.u will be
	  generated.
	- on IPv4/v6 dual stack node with RFC2553 section 3.7 support,
	  an IPv4 packet to x.y.z.u will be generated.
	the latter is what RFC2553 section 3.7 says, so the latter node is
	not compatible with SIIT.

	i fail to see your reasoning on the lines marked with arrow - why
	do an end node has to know about translator in the middle?  it breaks
	the rule #1 in Internet design.

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 24 Sep 2002 14:40:23 -0400

[email-masked] wrote:
> 	do an end node has to know about translator in the middle? 

Itojun

The node has to have some sort of address configuration where
it will actually acquire a translatable address.  Thus the node will
know that it is in a SIIT cloud and can make decisions appropriately...
such as apply SIIT requirements before applying RFC2553.

-vlad

>       it breaks

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: [email-masked]
Date: Wed, 25 Sep 2002 11:59:12 +0900

>such as apply SIIT requirements before applying RFC2553.

	yes, the presense of IPv4 translatable address (::ffff:0:x.x.x.x) could
	work as a hint to disable RFC2553 section 3.7 behavior.

	however,
	- it's documented in no place.
	- what will you do when you also have normal IPv4 address as well?
	  (including 127.0.0.1)
	- what if you already have AF_INET pcbs and/or IPv4-mapped AF_INET6
	  pcbs then acquire IPv4 translatable address?  what should happen to
	  those existing pcbs?

	there are huge amount of clarifications needed, and i'm not convinced
	if the additional complexities (for supporting SIIT) will help us.
	additional complexity equals to:
	- increased cost in implementing IPv6 stack = IPv6 looks less attractive
	- increased chances for security holes/interop issues/admin headaches
	so could we just agree on simple set of behavior (like "no IPv4 mapped
	address on wire") and move on?

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 10:34:40 +0200 (CEST)

> 	- increased cost in implementing IPv6 stack = IPv6 looks less attractive

I think the bulk of the added complexity is in allocating and renewing 
the IPv4-translatable address on demand (based on attempts to create IPv4
connections and maintain them). The sending rules complexity is rather minor
in comparison.

So I currently don't think the complexity of using SIIT (including the
address assignment) is worth while given the little likely benefits.

But I continue to completely disagree with you that the SIIT specification
and approach is somehow inconsistent with RFC 2553. They look very consistent
to me.

> 	address on wire") and move on?

Don't do it that way since it would mean that the IETF would have
two conflicting proposed standards; one which says to use the address on
the wire and one that says not to. That would be very confusing.
(Assuming there is rough consensus) the best approach would be to write
an explantory RFC which provides the motivation and move the SIIT specification
to HISTORIC.

   Erik

---

From: "Todd T. Fries" <[email-masked]>
Date: Wed, 25 Sep 2002 07:25:14 -0500

makes perfect sense to me ;-)
-- 
Todd Fries .. [email-masked]

(last updated $ToddFries: signature.p,v 1.2 2002/03/19 15:10:18 todd Exp $)

Penned by [email-masked] on Wed, Sep 25, 2002 at 11:59:12AM +0900, we have:
| >The node has to have some sort of address configuration where
| >it will actually acquire a translatable address.  Thus the node will
| >know that it is in a SIIT cloud and can make decisions appropriately...
| >such as apply SIIT requirements before applying RFC2553.
| 
| 	yes, the presense of IPv4 translatable address (::ffff:0:x.x.x.x) could
| 	work as a hint to disable RFC2553 section 3.7 behavior.
| 
| 	however,
| 	- it's documented in no place.
| 	- what will you do when you also have normal IPv4 address as well?
| 	  (including 127.0.0.1)
| 	- what if you already have AF_INET pcbs and/or IPv4-mapped AF_INET6
| 	  pcbs then acquire IPv4 translatable address?  what should happen to
| 	  those existing pcbs?
| 
| 	there are huge amount of clarifications needed, and i'm not convinced
| 	if the additional complexities (for supporting SIIT) will help us.
| 	additional complexity equals to:
| 	- increased cost in implementing IPv6 stack = IPv6 looks less attractive
| 	- increased chances for security holes/interop issues/admin headaches
| 	so could we just agree on simple set of behavior (like "no IPv4 mapped
| 	address on wire") and move on?
| 
| itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 09:15:59 -0400

> 	address on wire") and move on?

Once you clarify what you mean by "no IPv4 mapped address on the wire",
we can move on.

-vlad -