Subject: Re: (ngtrans) draft-ietf-ngtrans-6to4-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 May 2000 15:02:08 -0500

Eric,

No, we specifically forbid the use of RFC 1918 addresses to form the 6to4 prefix,
and this will be even more clear in the next version. The whole point of 6to4
is to create global prefixes, which by definition can't be done with RFC 1918
addresses.

This isn't a problem, because even if a customer only has one globally unique
IPv4 address, and all the rest are RFC 1918 addresses, that one is sufficient to 
generate all the IPv6 addresses the customer is ever going to need.

IPv6 has no equivalent of RFC 1918 addresses, and doesn't need them since
there is plenty of address space for everybody. The myth that private
addresses guarantee privacy will not be propagated in IPv6.

   Brian

"Klein, Eric" wrote:
> 
> Brian,
> 
> This draft it states:
>         5.8 Usage within Intranets
> 
>            There is nothing to stop the above scenario being deployed within
> a
>            private corporate network as part of its internal transition to
> IPv6;
>            the corporate IPv4 backbone would serve as the virtual link layer
> for
>            individual corporate sites using 2002:: prefixes.  The V4ADDR
> MUST be
>            a duly allocated global IPv4 address, which MUST be unique within
> the
>            private network. The Intranet thereby obtains globally unique
> IPv6
>            addresses even if it is internally using private IPv4 addresses
> [RFC
>            1918].
> 
> This may seem like a silly question, but is there an allocation of addresses
> to be used strictly for private networks similar to what is specified in
> RFC 1918        Address Allocation for Private Internets   February 1996
> 
> 3. Private Address Space
> 
>            The Internet Assigned Numbers Authority (IANA) has reserved the
>            following three blocks of the IP address space for private
> internets:
> 
>              10.0.0.0        -   10.255.255.255  (10/8 prefix)
>              172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
>              192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
> 
>            We will refer to the first block as "24-bit block", the second as
>            "20-bit block", and to the third as "16-bit" block. Note that (in
>            pre-CIDR notation) the first block is nothing but a single class
> A
>            network number, while the second block is a set of 16 contiguous
>            class B network numbers, and third block is a set of 256
> contiguous
>            class C network numbers.
> 
> This is a very valid need for private networks that are currently using
> these private networks, and wish them to remain private. There needs to be
> some method for both converting these on an IPv4 network that is
> transitioning to IPv6 network and in the final IPv6 network.