>> o Move any document that suggests the use of IPv4 mapped address on wire
>> to historic, due to security reasons.
>=> 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 :-).
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).
>> 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.
>=> 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!
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
