Subject: RE: A use for site local addresses?

From: Pekka Savola <[email-masked]>
Date: Tue, 1 Apr 2003 10:48:04 +0300 (EEST)

On Mon, 31 Mar 2003, Tony Hain wrote:
> Pekka Savola wrote:
> > Route advertisements with long-enough lifetimes and 
> > fast-enough _deprecation_ (when reconnecting) seems one 
> > approach to look at more 
> > closely, IMO.
> 
> Rather than continue to send this nonsense, please look closely at it
> because you will find that it is a seriously broken model. 

Wow -- wait a second, you threw the first rock.. :-)

> Deprecation
> at reconnection will cause internal connections to drop. 

Wrong.

"deprecated" in RFC2461 terms basically means "address is still assigned,
but don't establish new connections with the address" Deprecated addresses
can be used juuuust fine for existing connections.

deprecated != invalidated

> If you delay
> the deprecation, connections to the site with the valid allocation will
> not be possible. 

True, to an extent.

The big thing is the window between getting new addresses and deprecating
old ones; that is, ensuring that packets are not sourced with the old,
broken addresses to the _Internet_.

Which is why such windows must be minimized or eliminated, as above.

However, you could implement a source address check in the border router
-- like as proposed in host-centric multihoming -- so the nodes could pick
the right address, even in circumstances like this.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Apr 2003 14:38:01 +0200

Michel Py wrote:
> 
> Brian,
> 
> > Brian E Carpenter wrote:
> > IMHO it doesn't make a case for SLs in their present
> > incarnation (i.e. ambiguous address space).
> 
> Note that if the present state is still ambiguous, it's largely due to
> the fact that authors of drafts to make them unique (non-ambiguous)
> namely Bob Hinden, Charlie Perkins and myself have kind of put their
> drafts on the back burner waiting for this site-local turmoil to settle
> down.

Exactly. It was the present incarnation, not some possible future
incarnation, that I raised my hand against.

   Brian

---

From: "Michel Py" <[email-masked]>
Date: Wed, 2 Apr 2003 08:06:19 -0800

> Brian E Carpenter wrote:
> Exactly. It was the present incarnation, not some
> possible future incarnation, that I raised my hand
> against.

I would like to hear what Steve Deering, as author, has to say about all
of this too.

Michel.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 08:28:15 -0500

Hi Michel,

No one is planning to change anything in the last 24 hours...

The current addressing architecture has been approved for publication
at PS, and it will be published at PS (barring unforseen circumstances).

We are currently discussing what the IPv6 working group wants to do
in future versions of the addressing architecture and scoped addressing
architecture.  If we decide to deprecate site-local addresses, then
a new version of the addressing architecture will be produced that
deprecates site-locals.  It will be reviewed by the WG, sent to WG last
call, sent to the IESG for approval, etc...  All using the usual IETF
processes.

Margaret

At 08:05 AM 4/2/2003 -0800, Michel Py wrote:
>Really? By trying to sneak a major architectural change into a last 24
>hour "editorial" change? I am going to file an appeal about how this
>entire situation was handled on the first place.
>
>What kind of work is that? Gathering consensus on a text that nobody has
>seen because it does not exist yet? This consensus has no value and I
>will now push this issue all the way to the top.
>
>Michel.
>
>