Subject: (ngtrans) 6to4 on dynamic IPv4 addresses

From: Nathan Lutchansky <[email-masked]>
Date: Sat, 17 Feb 2001 11:30:43 -0500 (EST)

Hi,

It is possible to use 6to4 with a dynamically-assigned IPv4 address, and
this will probably be the common way for individual ISP customers like
homes and small businesses to get IPv6 connectivity during the
transitional period.  I'm modifying the Linux radvd daemon to watch for
IPv4 address changes on a specific interface and modify the RA prefixes
appropriately.  However, the DoS prevention in RFC 2462 seems to cause a
problem when prefixes are changed quickly.

Whenever the IPv4 address of the gateway changes, like when a PPP session
is disconnected and reconnected, the previous 6to4 prefix should
immediately be invalidated (not just deprecated) because no packets to the
old IPv4 address and 6to4 prefix can be received any longer.

Unfortunately, the DoS protection in section 5.5.3 of RFC 2462 requires
that when a prefix is suddenly invalidated in an RA that hosts must
deprecate it for two hours before invalidating it.  The only way to avoid
this "waiting period" is to use IPSec.

This isn't a problem for new communications in the scenario, since the new
preferred address becomes effectively immediately; old connections on the
deprecated/invalid address are broken anyway.  The problem is that if the
gateway changes IPv4 addresses more often than every two hours (on a noisy
phone line, for example), the number of deprecated addresses assigned to
each host grows without bound.

Is this an issue?  2462 doesn't state whether a host should invalidate
deprecated addresses that are no longer used by applications, and in
certain situations it would not make sense to do so.  How would current
protocol stacks handle having a new prefix more often than every two
hours?  -Nathan

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Feb 2001 08:37:24 -0600

The only real issue I can see is finding a 6to4 relay willing to handle
the traffic to/from a dynamic v4address, i.e. willing to handle any
v4address in the range used by the ISP concerned. And of course getting
DNS entries set up quickly if you need them.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Feb 2001 11:58:54 -0500

dynamic addresses are a real problem.   while it is of course understood
that sites must renumber from time to time in order to keep the routing
tables managable, the network should not be arbitrarily constraining the 
lifetime of addresses nor should ISPs be using this technique as a form 
of censorship.

6to4 doesn't help this, but it doesn't make it any worse either.

Keith

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 28 Feb 2001 12:06:18 -0500 (EST)

Well, right now, both Microsoft's inbound 6to4 relay and Cisco's outbound
6to4 relay seem to be wide open, so for the short term, willingness to
handle traffic isn't an issue.

The technical concern was whether current IPv6 stacks could handle
renumbering within very short time periods (like an hour), and I just need
to do some testing to figure out how each implementation handles this.
Once IPv6 is available natively, 6to4 and thus this problem won't be an
issue.  -Nathan

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 Feb 2001 12:17:57 -0800

Nathan,

There shouldn't be any issues with renumbering even on a per-connection
basis. The primary concern is host initiated (privacy based), or network
initiated. The latter should not occur very frequently just for operational
sanity, but there is nothing inherent which would prevent a host from
responding appropriately in an environment like your noisy line. The thing
you need to keep in mind is that all hosts are expected to handle multiple
addresses simultaneously, so renumbering is just another address on the list
and only becomes an issue at the instant of each connection (which address
do I use for this one?). How many addresses a host maintains in a
depreciated state, and how they flush that list when full, are
implementation details that will naturally adjust over time with customer
feedback. If you have implementation experience which shows that 2 hours is
inappropriately long, or that the number of depreciated addresses a host
will need keep track of is unmanageably large, please provide that. Current
expectations are that these numbers are within the bounds of reason.

Tony

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Nathan Lutchansky
Sent: Wednesday, February 28, 2001 9:06 AM
To: Brian E Carpenter
Cc: ngtrans mailing list
Subject: Re: (ngtrans) 6to4 on dynamic IPv4 addresses

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 28 Feb 2001 19:02:49 -0500 (EST)

On Wed, 28 Feb 2001, Tony Hain wrote:

> How many addresses a host maintains in a depreciated state, and how
> they flush that list when full, are implementation details that will
> naturally adjust over time with customer feedback.

I was actually wondering how those implementation details are specified
now.  To be precise: how is "full" defined, as you've used it above?  If I
renumber my network every 500 ms by advertising the old prefix as invalid
(lifetimes = 0) and advertising a new preferred prefix with infinite
lifetimes, how will each IPv6 implementation behave?  According to RFC
2462, hosts should actually deprecate the old addresses with a lifetime of
two hours rather than invalidate them immediately, assuming I'm not using
IPsec.  This is to prevent very simple DoS attacks.

So, will all implementations begin flushing the deprecated addresses after
more than X number of them have accumulated?  Or will some of them simply
accumulate addresses without bound until they have exhausted available
memory?  It looks like the Linux kernel will happily keep adding addresses
forever, which is probably not the most optimal/secure behavior.  Other
implementations I'm not sure about.  This raises questions about DoS
attacks involving advertisement of large numbers of bogus prefixes, but
I'm sure they were considered while RFC 2462 was in development and I
don't want to raise discussions that were settled in the past.

> If you have implementation experience which shows that 2 hours is

Two hours seems perfectly reasonable, especially if hosts keep a limit on
the number of deprecated addresses they retain.  Network administrators
(and home-router manufacturers) will simply need to keep the advertised
lifetimes of prefixes short enough when accomodating unusual situations
like 6to4 on a dynamic IP.  -Nathan