Subject: Re: SL deprecation draft

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2003 03:58:35 +0100

Pekka Savola wrote:
> 
> On Thu, 13 Nov 2003, Bob Hinden wrote:
> > So my take is that only the Address Architecture and Default Address
> > Selection documents need to be listed.
> 
> FWIW, totally agree here.  Listing those which had no issues of substance
> only confuse the reader.

That isn't completely clear to me. We could say something like:

This deprecation will require substantive updates to the Address Architecture 
and Default Address Selection documents [ref, ref].

The site local prefix is also mentioned in several other documents which need
at most minor editorial updates [ref, ref, ref...].

  Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 18 Nov 2003 09:26:23 +0200

Brian E Carpenter wrote:

> While I'd personally love to declare RFC 1918 "Historic", it really is
> completely IPv4 specific so we have no reason to reference it.

I would agree that RFC1918 is pure v4 issue, but we will need take into
account that when these IPv4 networks are connected as part of IPv6 networks
we could get flooded with a lot of the ::10.x.x.x addresses that are
supposed to be "site local" under IPv4, but are now neither site local nor
unique under IPv6.

This is where we need to put in text in the Depriciation document, othewise
we will end up with a lot of congestion and leakage from what used to be
behind NATv4 or just local RFC1918 local site addresses.
>
> Where can I find the NATv6 group? I have a few things I'd like to
> say to them...

It looks like [email-masked] or [email-masked] the group working
on the NAT issues.
>
>     Brian
>
> EricLKlein wrote:
> >
> > I think the most basic RFC one was missed from the list: RFC1918.
Especially
> > since the NATv6 group is probably working under the presumptions that
these
> > addresses, or ones like them, still exist in IPv6.