Subject: another input to IPv6 addressing architecture

From: [email-masked]
Date: Fri, 30 Aug 2002 08:17:27 +0900

i have another input to IPv6 addressing architecture, which is
	very securty-sensitive.  please review and integrate it before
	publishing the next one.
	draft-itojun-v6ops-v4mapped-harmful-00.txt

itojun

---
4.  Suggested protocol change

o In IPv4 address architecture document [Hinden, 1998] explicitly state
  that IPv4 mapped address is for use within basic API [Gilligan, 1999]
  , and basic API only.  Forbid any other uses.

o Move any document that suggests the use of IPv4 mapped address on wire
  to historic, due to security reasons.

The above change will remove the threat due to the use of IPv4 mapped
address on wire.

Another way is to deprecate RFC2553 section 3.7, however, due to the
wide deployment of applications that use IPv6 basic API, the option is
not feasible.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 29 Aug 2002 22:47:38 -1000 (HST)

>   , and basic API only.  Forbid any other uses.

You may recall someone (maybe it was you?) had suggested the issue of
using 'multicast' IPv4 mapped addresses in the API be handled in a
separate document rather than in the basic API.  It sounds like the above
suggestion would prevent that from happening at all if we ever came to
some agreement on the finer details.

> The above change will remove the threat due to the use of IPv4 mapped

This sounds reasonable.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Aug 2002 13:10:32 +0200

In your previous mail you wrote:

   
=> I don't like at all SIIT so I have no concern with this proposal.

=> you are a bit hard: these mechanisms should simply use other
injections of the IPv4 address space into the IPv6 address space
(there are many ways to inject a 2^32 space into a 2^128 one :-).

=> I agree this should be simpler so safer.

=> I strongly object to this part of your proposal. IMHO IPv6 is NOT
a new protocol, it is only a new version of the IP protocol. So the
right target is to provide an "all version" API, as it is easy to inject
IPv4 into IPv6, the section 3.7 is the right idea!

Regards

[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Aug 2002 08:05:21 -0400

Hi Itojun,

>   , and basic API only.  Forbid any other uses.

I don't have a problem with this concept.  In fact, I thought that we
had two ways to include an IPv4 address in an IPv6 address because one
was meant to be used on the wire and the other was not.  Was I confused?

>   to historic, due to security reasons.

Which documents would this include?  SIIT?  Any others?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Aug 2002 15:16:04 +0300 (EEST)

> was meant to be used on the wire and the other was not.  Was I confused?

You probably thought:

 1) mapped address --> API
 2) compatible address --> on the wire

But 2) no longer holds and people only see "1)" as the only "standard way"
to get to their goals.

> Which documents would this include?  SIIT?  

Only non-algorithmic portions of SIIT. (Or else NAT-PT should have to be 
rewritten to be independent).

> Any others?

The -00 nat64-nat46 draft.

-- 
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: [email-masked]
Date: Sat, 31 Aug 2002 00:24:57 +0900

>The -00 nat64-nat46 draft.

	draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt

itojun

---

From: [email-masked]
Date: Sat, 31 Aug 2002 00:49:59 +0900

>(there are many ways to inject a 2^32 space into a 2^128 one :-).

	SIIT and NAT64 takes advantage of the "confusion" regarding to IPv4
	mapped address, so they have no other choice (or they will require
	changes to nodes in SIIT/NAT64 cloud).

>IPv4 into IPv6, the section 3.7 is the right idea!

	please be sure to read the whole draft.

	i disagree that RFC2460 section 3.7 is a good idea, as it adds a lot
	of complication into the kernel API (AF_INET setsockopt operations
	on AF_INET6 socket, multicast, complicated and unauditable tcp/udp/pcb
	layer).  it seems right for shortterm porting, but it actually hurts
	people in long term.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Aug 2002 14:56:34 +0200

=> I read it when you posted it in the bugtraq list..

   	i disagree that RFC2460 section 3.7 is a good idea,

=> this is a matter of taste and obviously we deeply disagree.

        as it adds a lot of complication into the kernel API (AF_INET
        setsockopt operations on AF_INET6 socket, multicast, complicated
        and unauditable tcp/udp/pcb layer).

=> this is not so hard and one stack supporting the two versions is
simpler than two different parallel stacks for each version.

        it seems right for shortterm porting, but it actually hurts
        people in long term.
   
=> my target is not easy short-term porting, it is more a long term
and philosophical issue.

Regards