Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:24:50 -0400

The default should be public.  Thats the Internet way.  Temp is means Temp.  If you want to make a phone call over VoIPv6 and you have a temp address my phone call could be killed or paused waiting for renew.  I find that kind of rude.

Default should be public temp should be an option.

Also give me one technical reason why it should be temp.

/jim

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 6:29 PM
> To: Keith Moore
> Cc: Thomas Narten; [email-masked]
> Subject: Re: IESG comments on
> draft-ietf-ipngwg-default-addr-select-06.txt 
> 
> 
> > I respect the desire for temporary addresses (and AFAIK I 
> was one of 
> > the first people to raise concerns about embedding tracable 
> information
> > in an IPv6 address) but I don't think it's a good idea to 
> effectively
> > change the API in a way that would break apps at this late date.
> 
> The proposed text is trying to say that temporary addresses 
> are preferable
> but that there might be issues (such as applications having problems)
> which consistitute a good enough reason to not follow the default.
> Thus there is significant freedom for implementors to use their best
> judgement based on their knowledge about the applications.
> 
> Do you see a problem with this approach?
> 
>    Erik
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Alberto Escudero-Pascual <[email-masked]>
Date: Thu, 13 Jun 2002 21:44:46 +0200 (CEST)

Hi Jim!

If only the users that have concerns about privacy will end up using temp
addresses (RFC3041) we will end up with a minority group of techno-geeks
or as you call us 'paranoids' highly observable and easy to identify from
the crowd.

I firmly beleive that RFC3041 should be the default option and only the
nodes that require a fixed address should enable that option. 'Privacy'
should  be the default option. I don't want to be sorrounded by boxes with
EUI-64 based addresses and be myself the only one running RFC3041.

/aep

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Thu, 13 Jun 2002 21:50:06 +0200 (CEST)

Time ago i wrote a paper concerning the observability of RFC3041 and the
famous u=0 bit in the address.

http://www.it.kth.se/~aep/publications/rvk02-escuderoa.pdf
Escudero A, Requirements  for  unobservability  of privacy extension in IPv6.

/aep

-- 
--------------------------------------------------------------------------
 A "No" uttered from deepest conviction is better and greater than a
 "Yes" merely uttered to please, or what is worse, to avoid trouble.
							Mahatma Gandhi

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 16:01:28 -0400

> should  be the default option.

no. 
having apps work should be the default.
having the reasons for failure be obvious should be the default.
having the apps determine whether they need private addresses or not
(after all, they're the ones that know) should be the default.

I have every confidence that apps that can make use of private
addresses, will do so if we give them a uniform API to work with.

if you really want privacy to be the default, unplug your network.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 16:28:33 -0400

> I have also the confidence that apps that require the use of PUBLIC
> fixed addresses, will do so if we give them a uniform API to work with.

we've had that API for 20+ years now.  what we're arguing about is
whether to change it.  I say "no".
--------------------------------------------------------------------
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: Alberto Escudero-Pascual <[email-masked]>
Date: Thu, 13 Jun 2002 22:24:20 +0200 (CEST)

/aep

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Jun 2002 15:27:38 -0700

Keith,

get off the soap box... IPv6 requires a new API, so there is no valid
argument that we are not changing it. If you want to argue that we
should minimize the changes, I would agree.

Tony

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Keith Moore
> Sent: Thursday, June 13, 2002 1:29 PM
> To: Alberto Escudero-Pascual
> Cc: Keith Moore; Bound, Jim; Erik Nordmark; Thomas Narten;
> [email-masked]

---

From: [email-masked]
Date: Fri, 14 Jun 2002 07:34:46 +0900

>should minimize the changes, I would agree.

	no more changes, *please*.  we have spent more than reasonable amount
	of years to settle down to RFC2553/bis.  and people are now using it.

	I would quote words from sendmail people - "first gethostbyname2,
	then gethostbyname3, then getipnodebyname, then you want us to
	switch to getaddrinfo?  how can we know that it will be the final one?"
	I was so embarrassed when i heard this.

itojun

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 18:34:13 -0400

> should minimize the changes, I would agree.

believe it or not there are already lots of progams using the v6 API...
many of which were very slight modifications to v4 programs.

I'm happy that IESG has decided not to insist on temp addresses as
the default and has backed the idea that there should be an API
to request them.  Now, who's going to define the API extension? 

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Jun 2002 15:37:29 -0700

> (after all, they're the ones that know) should be the default.

Your logic doesn't make sense. In fact the app that needs a fixed
address should know that, and one that can live with a variable one
probably has no idea what address is being used anyway.

> addresses, will do so if we give them a uniform API to work with.

Any app that doesn't need a forward or reverse record in DNS will work
with a private address, why do they need a special API. What you are
looking for is a simple way during address selection to know which
address is recorded in DNS.

> if you really want privacy to be the default, unplug your network.

That is not what private addresses are for and you know it. Rather than
bash the new concept for being different, why not provide a constructive
proposal like a flag on the local address list to know which have been
recorded in DNS?

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 18:43:41 -0400

> probably has no idea what address is being used anyway.

the problem is there's a large body of code out there written
to assume fixed addresses because that's been the API for 20+
years.

if we were starting from scratch I might agree with you.
 
> with a private address, 

uh, no.  DNS isn't the only way that apps get addresses, and some
apps need stable addresses whether or not they're listed in DNS.

> What you are

no. not even close.

> proposal like a flag on the local address list to know which have been

because it wouldn't solve the problem.  I already made a constructive
proposal that does solve the problem.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Jun 2002 15:23:07 +0200 (CEST)

> with a private address, why do they need a special API. What you are

Nope. Temporary addresses will not be useful for more than 7 days (using
the default timers). Thus if I e.g. want a telnet session to stay up for
many weeks the telnet application needs a non-temporary address indepedent
of any DNS related stuff.

  Erik

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 21 Jun 2002 10:23:20 +0200

Hello,

> address is recorded in DNS.

Thats not true. Applications that need an identified source address (or their
peer that requires to see an identified destination address) won't work
with temporary addresses - unless you give the whole /64 prefix the same
IPSEC identification, in which case doing so is mostly useless.

This is independent of DNS.

Regards,
	-is

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jun 2002 17:29:23 +0200

In your previous mail you wrote:

=> as a hot defender of protocol 50 I don't follow you...

=> in fact we have the choice between to keep the u/g bit stuff with
consequences like RFC 3041 or just to throw this heritage of 8+8
(because now we know how to do a secure two-space system: HIP) and:
 - forget the universal bit
 - rely on DAD in order to avoid IID collisions
 - reduce IID size (32 bits are enough for common links)
 - weaken the IID to a host part
etc.
Perhaps this is too late but I'd like to see a sound opinion, i.e.,
not in the same time dreaming over adding some semantics to bits
in IIDs and reject our IMEI based IID draft with spurious arguments
(perhaps in Japan where there are tens of millions of phones with
data services, i.e., a need for an universal IID registry, things will
be a bit different :-).

Regards

[email-masked]

PS: my very personnal opinion is 64 bit IIDs are a huge waste of
address space.