Subject: Are IPv6 auto-configured addresses transient?

From: Vijayrajan ranganathan <[email-masked]>
Date: Wed, 7 Oct 2009 21:55:18 +0530

Hi Everyone,
Is there a notion that auto-configured IPv6 addresses based on
globally unique prefixes are transient compared to manually configured
ones?
I know that we could configure them to have infinite lifetimes & such,
but I am thinking of a large IPv6 deployment where these addresses are
expected to be up 24/7. I mean, just the fact that lifetimes could be
modified on the router, the advertising router could become
unreachable etc.

As an IPv6 application developer, would I have to factor in this
"transiency" of autoconf addresses in my design all the time? How safe
& normal
is it to replace all manual IPv6 address configuration with
auto-configuration in a large IPv6 deployment esp in an environment
that is very sensitive
to non-availability of addresses?

Another related question, is it common for a site's global prefix(es)
to change? In this regard, are they any different from an IANA
assigned IPv4
network-id for example?

Thanks & Regards
Vijay

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 7 Oct 2009 07:00:13 -1000 (HST)

> globally unique prefixes are transient compared to manually configured

It depends.  SLAAC-created addresses are pretty much fixed as long as the 
device isn't moved to another network and it's ethernet port swapped out 
with another.  Addresses for anonymity might be considered transient since 
they seem to change upon reboot.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Oct 2009 11:02:14 +1300

Vijay,

I think it's been safe to say for many years that *all*
IP addresses, of either family, are transient, with limited
exceptions (i.e. stable servers). I don't see that IPv6
autoconf addresses are qualitatively different in that respect.

It is a deep design bug that when applications obtain an address
from lower layers, it doesn't come with a lifetime attached.
Addresses derived from A or AAAA records, DHCP or DHCPv6, etc.,
all have finite lifetimes, and it's very sad that applications
don't know it.

Actually let me plug the GROBJ BOF in Hiroshima, and the associated
draft-carpenter-behave-referral-object (version 01 coming soon).
Address lifetime becomes an especially serious problem when
referring addresses from one host to another.

   Brian

On 2009-10-08 05:25, Vijayrajan ranganathan wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Oct 2009 15:15:35 -0700

On Oct 7, 2009, at 10:00 AM, Antonio Querubin wrote:

> It depends.  SLAAC-created addresses are pretty much fixed as long  
> as the device isn't moved to another network and it's ethernet port  
> swapped out with another.  Addresses for anonymity might be  
> considered transient since they seem to change upon reboot.

or to change periodically, such as once a day.

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 08 Oct 2009 13:04:24 +0900

Hi Vijay

Speaking from an ISP operator's point of view,

> auto-configuration in a large IPv6 deployment esp in an environment

I would not want to replace manual confiburation with auto-config.
Not now, at least. Most of my network is manual configured.

> to change? In this regard, are they any different from an IANA

Customers don't like it when we ask them for a change of addresses.
I don't think that's going to change with IPv6 anytime soon but
it does happen, although not very often in my place.

Regards,
Seiichi

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 15 Oct 2009 21:41:56 -0400

Hi Vijayrajan,

> globally unique prefixes are transient compared to manually configured

Auto-configured global IPv6 addresses are "leased" to an interface for  
a specified "lifetime".  They expire at the end of that lifetime if  
the lifetime is not renewed.

> to non-availability of addresses?

Typically, IPv6 router advertisements will advertise fairly long (at  
least several hour) lifetimes for their prefixes, and those lifetimes  
are renewed each time a hosts receives another router advertisement,  
which should happen quite often.

Also, when the address lifetime expires, the addresses do not go away,  
they are merely deprecated.  They will continue to be used for ongoing  
communication, and may be used for new communication if no other  
addresses are available.  So, prefix lifetimes offer a way to replace  
an existing address with a new address when the network configuration  
changes, but they do not prevent continued local communication if the  
only router (or every router) goes down for an extended period, for  
example.

> to change? In this regard, are they any different from an IANA

Most global prefixes in IPv6 are provider-assigned, so they would  
change if you change ISPs, or perhaps if your ISP changes their  
network configuration.  Some registries do seem to over provider- 
independent IPv6 addresses, but I don't know all of the details about  
how you would get one of those and/or how you would get an ISP to  
route it.  You'd need to contact a registry and your ISP to work that  
out.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Oct 2009 13:35:24 -0400

Hi Margaret,

Margaret Wasserman wrote:
> Auto-configured global IPv6 addresses are "leased" to an interface for a 
> specified "lifetime".  They expire at the end of that lifetime if the 
> lifetime is not renewed.
> 
> addresses are available.  So, prefix lifetimes offer a way to replace an 
> existing address with a new address when the network configuration 
> Most global prefixes in IPv6 are provider-assigned, so they would change 
> if you change ISPs, or perhaps if your ISP changes their network 
> configuration.  Some registries do seem to over provider-independent 
> IPv6 addresses, but I don't know all of the details about how you would 
> get one of those and/or how you would get an ISP to route it.  You'd 
> need to contact a registry and your ISP to work that out.
> 

I *think* that Vijay is asking a more general question about 
applications rather than how to get IPv6 addresses (or service).  If I 
interpreted his earlier comments correctly, he is asking what does an 
application know about an address that it is using.  For example, if 
Vijay's application is long-lived would it be affected by an address 
becoming deprecated and no longer reachable.  In this case, the address 
stays reachable for some period of time until the deprecated prefix is 
removed from the routing system.

I suppose there is a related question as to how an application that uses 
IP addresses in referrals should behave.  Would an application find it 
useful to know the lifetime associated with the auto-configured addresses?

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 18 Oct 2009 09:28:17 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
>Sent: Friday, October 16, 2009 1:35 PM
>To: Margaret Wasserman
>Cc: [email-masked]
>Subject: Re: Are IPv6 auto-configured addresses transient?

>removed from the routing system.

I don't see any problem here.  Till a specific long-lived application
screw case is described, I am not convinced the app needs to know
anything related to lifetimes of addresses.  On an IPv6 node, if
anything related to the addresses on a network interface changes, the
changes will affect the network interfaces the app is using.  Even in
IPv4, if an app is using an IP address of a network interface on the
node, the app tracks changes of the IP address on the network interface
- so IPv6 apps should do the same.     

>useful to know the lifetime associated with the auto-configured
addresses?

It may make sense that referrals for IPv6 do not merely use IP addresses
but switch to using a PIO (Prefix Information Option from RFC 4861) per
address.  The PIO contains the Prefix Lifetime.

Hemant

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 18 Oct 2009 17:01:24 -0400

> screw case is described, I am not convinced the app needs to know

I have a long lived ssh session between two devices, both of which use
enhanced privacy addresses that rotate hourly.

(example provided)

Note that in most cases the ip address stays live on the device as
long as there's something actively using it... so its not really a
problem, unless the entire subnet changes (upstream provider change
for instance).

> node, the app tracks changes of the IP address on the network interface

The app MAY track this info, it MAY also not :( sadly some people
hardcode the ip address into the application, of course you can't fix
that case.

-chris

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 18 Oct 2009 18:34:19 -0400

-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Sunday, October 18, 2009 5:01 PM
To: Hemant Singh (shemant)
Cc: Brian Haberman; Margaret Wasserman; [email-masked]
Subject: Re: Are IPv6 auto-configured addresses transient?

>enhanced privacy addresses that rotate hourly.

If the addresses rotate at the hour, then a callback function from the interface can call the app and report the change.  It's not even that an app has to track the interface IP address changes - the app just needs to register a callback to the interface ip address change processing function.  Even in v4 IP addresses can change by the hour and many v4 apps have been developed sensibly.

>hardcode the ip address into the application, of course you can't fix

Agreed.  Well, I state a simple coding mechanism above.  The apps have to do better now.  I think for such issues mentioned, some well-known proper coding practices exist. It up to BEHAVE to see what, if anything, needs specification here.  I am still not convinced a problem exists here for which the IETF has to do anything about.  I am definitely convinced on the referral IP address that Brian mentioned in that the referral needs some thought.

Thanks,

Hemant

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 Oct 2009 10:13:13 +1100

One thing we do need to do is to push more address state into the
DNS.  Today we just have AAAA records.

We want to able to map from address to names and names to addresses
as long as the mappings exist.

We also want to stop using deprecated addresses as soon as possible.

AAAA doesn't have enough information to meet both needs.  We can
remove deprecated address but then we loose the ability to map.

We can keep the deprecated addresses but then we don't preference
the non deprecated address when establishing new sessions.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Oct 2009 13:10:35 +1300

Hemant,

On 2009-10-19 11:34, Hemant Singh (shemant) wrote:
...
> Agreed.  Well, I state a simple coding mechanism above.  The apps have to do better now.  I think for such issues mentioned, some well-known proper coding practices exist. It up to BEHAVE to see wh…

Please come to the GROBJ BOF in Hiroshima. Basically, I would
argue that all addresses have to be regarded in some sense
as transient (and that most applications are defective in this
respect). It's particularly acute, as Brian H said, in the
case of referrals.

http://tools.ietf.org/bof/trac/wiki/BifIETF76

  Brian Carpenter

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 20 Oct 2009 15:44:31 -0400

Brian,

Please see in line below.

Brian Haberman

>useful to know the lifetime associated with the auto-configured
addresses?

I did think about referrals and now have a response.  Any XYZ protocol
that sends referrals in control messages should already have mechanism
in place to send a control message for a referral update.  If the XYZ
doesn't have such control, then the XYZ protocol should add it.  I would
still stay away from sending lifetime of an address to an app.  Likewise
for sending lifetime to DNS when graceful renumbering already exists as
defined in the RFCs.  Personally I never get convinced for IETF taking
any new work to specify any behavior if folks mention to me a corner
case for a problem - like in the DNS email Mark Andrews sent.

Hemant