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 06:55:58 +0900

>Itojun,
>
>This is just common implementation sense.  I have never seen a v4mapped
>configured on any interface in any bake-off nor any developer ever
>suggest permitting it?

	i guess you are talking about different thing.  Vladislav was talking
	about an implementation where sendto(::ffff:a.b.c.d) on AF_INET6 socket
	will result in raw IPv6 packet with ::ffff:a.b.c.d in IPv6 destination
	address field.  we are not talking about configuring IPv4 mapped
	address onto interfaces.

	the behavior Vladislav mentioned looks way too weird to me, given
	conditions given in RFC2553 3.7 (which suggests me that the sendto()
	will result in IPv4 packet to a.b.c.d).

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 18 Sep 2002 11:13:52 -0400

Itojun

> 	address field.  we are not talking about configuring IPv4 mapped

Well, these 2 items are somewhat related, but different.  Using you
example above, if you are sending to ::ffff:a.b.c.d you need to figure
out the source address.  If the source address was explicitely specified,
you can't really do much (either send appropriately, or error).  If the
source address was not specified, you need to pick one and apply some
common sence.  If you don't have any IPv4 addresses, but have an SIIT
subsystem, then you are going to try to use it, right???

The mapped address on the interface, applies to your claim that IPv4-mapped
IPv6 address are dangerouse on the wire and difficult to filter.  In fact,
they are not that difficult.  Since these addresses are usually not
configured IPv6 interfaces of a node, the implementations will simply
regect the packet as "not for this destination".  The routers will usually
drop the packet with "no-route" error, unless it's a SIIT box or the
router actually has a route to ::ffff:0:0/96.

> 	will result in IPv4 packet to a.b.c.d).

The conditions of 2553 assume that you have an "dual stack" system with
IPv4 addresses available.  It that case, you don't need SIIT and the
packet will be treated as IPv4.

> itojun

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

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Sep 2002 00:37:33 +0900

>subsystem, then you are going to try to use it, right???

	this depends on how you implement "IPv4 mapped address on IPv6 native
	packet".
	- you could have special code that does it and have IPv4 address only
	  on your interface
	- you could have IPv4 mapped address on your interface and use them.

>router actually has a route to ::ffff:0:0/96.

	routers usually forward them blindly (default route).

>packet will be treated as IPv4.

	i disagree.  RFC2553 talks about API and IPv4/v6 readiness of the stack,
	and does not really talk about how interface addresses are configured.

	and the behavior your have been describing (if there's no IPv4 addrses
	put IPv4 mapped address directly into IPv6 packet) is not on any part
	of the documents.

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 18 Sep 2002 13:40:00 -0400

Hi Itojun

> 	- you could have IPv4 mapped address on your interface and use them.

Not exactly, but yes... it is a matter of implementation. Only the SIIT
translator will be sending out packets with a v4-mapped source address, but
that address does not belong to the translator (it belongs to the IPv4
source).  An IPv6 node in a SIIT clound would have to have a
translatable address, and then it's a matter of implementation of how it's
configured and on which interface.

But now we are going too deep into implementation space...

> 	routers usually forward them blindly (default route).

If they have a default route...

> 	and does not really talk about how interface addresses are configured.

I didnt say that 2553 talks about this.  I said the spec assumes that it
will be the general case.  That's why it suggests that mapped addresses be
on by default. (at least that's my interpretation)

But anyway, it sounds like what you would like is to say something like
"IPv4-mapped IPv6 addresses SHOULD NOT appear on the wire" in the IPv6
node requirements doc.  That would be OK, as it would permit an 
implementation that understands all the raminfications of v4-mapped
addresses (like SIIT) to use them.

However, absolutely forbidding mapped addresses is too harsh and a lot
of the harmful effects that you pointed out in your daft are mostly due to
lack of full understanding by application writers.  Most major
vendors already have very good explanations of how to use v4-mapped
addresses in their documentation.  Do you think an informational draft
would also be in order?

> 	put IPv4 mapped address directly into IPv6 packet) is not on any part

It seemed a common sense approach to me...

-vlad

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Sep 2002 02:48:14 +0900

>If they have a default route...

	they usually do, unless they are in the DFZ.

>addresses in their documentation.  Do you think an informational draft

	my take is that operating system vendors has to take a security stance,
	and provide safe API.  application writers are clueless.  they don't
	know what kind of checks he has to run through after getpeername(2)
	to make their apps secure.  i can give you tons of examples where
	people do not check IPv4 mapped address, and blindly use values got
	from getpeername() into sendto() - so creating chances to bad guys
	to inject bad IPv4 traffic from IPv6 cloud.  this is why i put section
	5.1 into my draft.

	i suggest you to read paper by Todd Miller on strlcpy() on usenix
	annual (or freenix?) a couple of years ago, for instance.

>It seemed a common sense approach to me...

	i don't think so.
	i would like to hear what other vendors do exactly, for instance,
	your sender rule on IPv4 mapped address.  source code would be nice,
	but if not possible, pseudo code is okay.  what we've done is
	open on ftp.kame.net and ftp.*bsd.org.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Sep 2002 21:08:39 +0300 (EEST)

> 	they usually do, unless they are in the DFZ.

"2000::/3 should be enough for everyone"

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Sep 2002 03:28:05 +0900

>"2000::/3 should be enough for everyone"

	that's not how we operate non-DFZ network around here.  if you
	aggregate to 2000::/3, you'd need to update your route
	filters/aggregate settings/whatever when other routes show up.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Sep 2002 22:44:00 +0300 (EEST)

> 	filters/aggregate settings/whatever when other routes show up.

I'm not sure I understand your comment.

The point of 2000::/3 is that with current IANA assignments, there is no
need for "another" default route.  But it excludes ::/16, for example
mapped addresses.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Sep 2002 05:18:51 +0900

>need for "another" default route.  But it excludes ::/16, for example

	i'm just saying that we configure default route, as well as "reject"
	routes for ::/96 such.  both of us are making correct configuration.

itojun

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 19 Sep 2002 12:00:42 +0200

Hello Itojun,

>Hi Itojun
<clip>

>addresses in their documentation.  Do you think an informational draft

Some of the proposals making use of ipv4-mapped addresses 
(draft-ietf-ngtrans-bgp-tunnel-04.txt, 
draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt) do not use these addresses as Source 
Addresses nor as Destination Addresses; they use the IPv4 mapped addresses 
in fields inside the payload (e.g. BGP Next Hop) whose semantic is defined 
by the field and by the proposals themselves (the spec explicitely defines 
that if the BGP Next Hop is encoded as an IPv4-mapped address, then the BGP 
recursion must be done on the embedded IPv4 address).
In such contexts, I don't think the potential issues you raised actually apply.
Basically we have an IPv6 field (BGP Next Hop address) which must convey an 
IPv4 address. This is exactly what IPv4-mapped addresses are defined for. 
And there does not seem to be any possible confusion in that context. Can't 
why we woudl need to change such proposals. Note also that there are 
successful implementations of this today.

So, I guess I agree with Vlad's recommendation that v4-mapped addresses 
should not be arbitrarily forbidden for all applications. If there are 
potential concerns for some applications, maybe those could be flagged. But 
my perception is that there are valid applications for IPv4-mapped.

Cheers

Francois

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 20 Sep 2002 00:25:12 +0900

>successful implementations of this today.

	question: without BGP capability negotiation BGP daemons will be
	tricked to use IPv4 mapped address in an unexpected way.
	does capability negotiation in draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt
	cover section 3.1, or which part of the document?  it is not very
	clear to me which part of document is capability-negotiated.

itojun

---

From: [email-masked]
Date: Fri, 20 Sep 2002 10:21:45 +0200

I'm not sure how you see BGP daemons being tricked by the proposed use
of IPv4 mapped addresses in draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt. The
BGP routes being advertised belong to a specific VPN-IPv6 address
family, and carry specific BGP/MPLS VPN attributes such as the Route
Target attribute. The draft explains, for this particular context, how
VPN IPv4 mapped addresses in the BGP next hop field MUST be interpreted
and used. 

>         clear to me which part of document is capability-negotiated.

In section 4, the draft says that BGP capability negotiation must be
used to ensure that peers are able to properly process VPN IPv6 NLRI.
Proper use of this NLRI implies proper interpretation of the IPv4 mapped
addresses in the BGP next hop field.

Jeremy.

---

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

> 	- you could have IPv4 mapped address on your interface and use them.

Why would you assign an IPv4-mapped address to an interface? No specification
I know of requires this.

In SIIT an IPv4-translatable address is assigned to the interface on the 
IPv6-only node. This address needs to be the source address for IPv6 packets
that are sent to the SIIT translator.
The translator doesn't assign IPv4-mapped addresses to an interface; instead
it has rules for when to apply translation.

   Erik

---

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

>Why would you assign an IPv4-mapped address to an interface? No specification

	i wouldn't, but Vladislav suggested it.

itojun

---

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

> 	i wouldn't, but Vladislav suggested it.

Woooooo..... When did I suggest that???

-vlad

---

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

>Woooooo..... When did I suggest that???

	see attached.

itojun

Subject: Re: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt
From: Vladislav Yasevich <[email-masked]>
To: Jun-ichiro itojun Hagino <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, [email-masked]
Date: Tue, 17 Sep 2002 13:42:38 -0400

Itojun

Jun-ichiro itojun Hagino wrote:
> 	(since this is transition tool discussion replies to ngtrans please)
> 
> 
>>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.
> 
> 
> 	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.

This packet will only go out as an IPv4 packet if there was an IPv4 address
available.  If the node implements SIIT and there is not IPv4 address, the
packet will go out as a SIIT formatted IPv6 packet (i.e with a translatable 
source.

A node that does not implement SIIT that happens to receive a SIIT formatted
packet will simply drop the packet because ::ffff:a.b.c.d IPv6 address is
not configured on any IPv6 interfaces of the node.

-vlad

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

---

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

Itojun

Please re-read what I wrote very carefully...

[email-masked] wrote:
> packet will go out as a SIIT formatted IPv6 packet (i.e with a 
> translatable source.

Please note that I said "translatable source".

> not configured on any IPv6 interfaces of the node.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

See the above the sentence...

I really don't know where you got the idea that I would even suggest that
v4-mapped addresses be configured on the nodes' interfaces... !?

-vlad

---

From: [email-masked]
Date: Thu, 26 Sep 2002 11:31:06 +0900

>> packet will simply drop the packet because ::ffff:a.b.c.d IPv6 address is <--

	your example (::ffff:a.b.c.d) on the line marked by arrow is an
	IPv4 mapped address, not an IPv4 translatable address
	(::ffff:0:a.b.c.d).

itojun

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 26 Sep 2002 09:20:32 -0400

Itojun

> 	IPv4 mapped address, not an IPv4 translatable address

I think I see where you got your interpretation.  Even though I
did NOT "suggest" that v4-mapped addresses are configured on
the interface, I can see how you could have considered that
"suggestion" implied in the wording.

Let me clarify.  A SIIT formatted packet has either v4-mapped
or v4-translatable destination (depending on the direction of
the packet).  If a host does not implement SIIT, it will not
have these addresses and will drop the packet.
If the host implements SIIT, it may have a v4-translatable
address and may accept the packet with that destination.
It will still drop the packet with a v4-mapped destination.

Hopefully that cleares things up.

-vlad