Subject: Re: [RRG] Consensus check: renumbering - missing dimension

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2008 11:06:29 +1200

On 2008-08-23 19:48, Tony Li wrote:
>  
> Hi Robin,
> 
> 
> |BTW, I found that the poll URL generated a "No such poll" response.
> 
> Indeed.  Mea culpa.  Sorry, I don't know how that got corrupted.  Here's the
> correct poll:
> 
> http://www.doodle.ch/participation.html?pollId=ziu439pxxpcx33da

I was about to click enthusiastically on choice #3 when
I realised that I really wanted to discriminate between
IPv4 and IPv6.

For IPv4, I consider that the train left the station many years
ago, and the only reasonable answer is "None at all." For IPv6,
habits are not yet set in stone, and I think we should stick to
our guns, so the reasonable answer is "Once per ISP added or dropped."

The reasoning is that IPv6 was designed that way, so why not
use the feature if it proves to be useful, at least for small/medium
sites.

    Brian

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Tony Li" <[email-masked]>
Date: Sun, 24 Aug 2008 16:22:40 -0700

|The reasoning is that IPv6 was designed that way, so why not
|use the feature if it proves to be useful, at least for small/medium
|sites.

Do folks really feel that stateless autoconfig is a significant step forward
vs. DHCP?  Current dual-stack site admins would be especially welcome to
opine.

Tony

---

From: Scott Brim <[email-masked]>
Date: Mon, 25 Aug 2008 17:13:45 -0400

> vs. DHCP?  Current dual-stack site admins would be especially welcome to

Speaking in relative ignorance but reporting ... I was talking to
someone a few days ago who bemoaned what he saw as a lack of
administrative control with stateless autoconfig.

---

From: "Christopher Morrow" <[email-masked]>
Date: Mon, 25 Aug 2008 17:28:13 -0400

> vs. DHCP?  Current dual-stack site admins would be especially welcome to

stateless-autoconfig is entirely not sufficient for site admins to use
in a 'renumbering' event. There are many items passed out in DHCP
responses which are used by the end systems and not included in
stateless-autoconfig. Existing practices account for these items via
DHCP in a mostly centralized manner, without these items site-admins
will be left with no option but to manually touch each device...

Take a moderately large enterprise of 50k systems in a global setting,
how long will it take to touch each of the 50k devices and change even
the basics: dns-server, wins-servers, domainname  (assume you can not
'trust' the system owner/user to get this right, and assume you have
limited helpdesk-staff).

-chris

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 10:35:03 +1200

> 'trust' the system owner/user to get this right, and assume you have

My memory is that back when stateless auto-config was conceived,
the main target was the "dentist's office" scenario, i.e.
basic Appletalk-like zeroconf sites. Unfortunately we still
have one hole in this area: no way to advertise a DNS server
address in RA messages. See RFC 4339.

I'm quite sure that larger sites with any kind of IT management
will need DHCPv6.

But I don't see why that interacts with the multi-prefix issue.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Mon, 25 Aug 2008 18:08:02 -0700

|I'm quite sure that larger sites with any kind of IT management
|will need DHCPv6.
|
|But I don't see why that interacts with the multi-prefix issue.

There was an assertion made by someone that IPv6 was going to be
significantly easier to renumber.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 13:16:25 +1200

> significantly easier to renumber.

s/easier/less awful/

But I think the reason is not specific to stateless-autoconf or DHCPv6.
In my mind it's because v6 prefixes will never be in desperately
short supply, so the normal model is add/deprecate/drop rather than
replace. That's the point of RFC 4192.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Mon, 25 Aug 2008 18:28:24 -0700

|But I think the reason is not specific to stateless-autoconf or DHCPv6.
|In my mind it's because v6 prefixes will never be in desperately
|short supply, so the normal model is add/deprecate/drop rather than
|replace. That's the point of RFC 4192.

Hmmm... Ok, to my mind that only addresses one small part of the pain.  ;-)

If we have an architectural solution then we're renumbering identifier
prefixes then those shouldn't be 'hard' to get either.  

Tony

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 25 Aug 2008 23:04:54 -0500

> vs. DHCP?  Current dual-stack site admins would be especially  

Not really.  We've been viewing it as a placeholder
until DHCPv6 clients get deployed further.  (Vista
ships with one today).

The unmanagedness of SLAAC is distasteful to enterprise
network admins (and RFC3041 further irritates them).

Cheers,

Dale
AS59 & AS2381

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 25 Aug 2008 23:13:46 -0500

On Aug 25, 2008, at 5:35 PM, Brian E Carpenter wrote:
> basic Appletalk-like zeroconf sites.

And IPX had it, often on a much larger scale (we had
thousands of hosts using it).

> Unfortunately we still have one hole in this area: no way to
> advertise a DNS server address in RA messages. See RFC 4339.

RFC 5006 now provides this, although I only know of one
implementation.

Cheers,

Dale
AS59 & AS2381

---

From: "Christopher Morrow" <[email-masked]>
Date: Tue, 26 Aug 2008 00:43:36 -0400

>  address in RA messages. See RFC 4339.

Sure, today the model for 'dentist office' or 'home user' is that some
widget does dhcp, provides a bunch of info users can't possibly
understand (reliably) and it's entirely baked into the client and
'widget' OS. Conceptually it's not hugely different from
stateless-autoconf, except that it exists today and has existed for
10+years in a form that is useful.

>  I'm quite sure that larger sites with any kind of IT management

yup, and hopfully there will be a method to make sure that joe always
has address X sally Y and billy Z... DHCP does this today, not
everyone uses it, but it's a handy option to have. Having the same
address regardless of the NIC in the workstation.

>  But I don't see why that interacts with the multi-prefix issue.

I don't think it does... except that today in the ipv4/dhcp world most
end stations have only one address. I don't think most
network/system-admin folks in the new ipv6 world want to have
workstations with more than one globally routable address, I could be
mistaken, but in the situations where I was the network or system
admin I really only wanted one address per end host where regular
users were involved. (servers can and often are different beasts, also
lower in number...).

Keep in mind also that pushing the autoconf on the networking gear
means that  the 'network admin' now has to be cognizant of every wierd
little option the 'system admin' people want to tweak/test/use/demand.
It's been a challenge in places to get the 'network admin' to put in:
"ip helper 1.2.3.4" even when given the exact string to put into his
configuration. Asking for repeated and often changes is likely to
cause operational headaches.

(I think we talked about the mixing of job-jars before though...)

-Chris

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Aug 2008 09:58:35 +0200

> 'trust' the system owner/user to get this right, and assume you have

End systems don't matter.  They are easy to renumber.  Harder are the 
routers, the name servers, and all the services that are contained 
within a DNS response.  Coordination with upstreams, change of ACLs, 
testing of perimeters, configuration of all IP-address aware systems, 
etc.  Almost none of that is the end host.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 26 Aug 2008 10:32:06 +0200

On 26 aug 2008, at 0:35, Brian E Carpenter wrote:

>> in a 'renumbering' event.

I've tried it, and it works really well. The advantage here of  
stateless autoconfig over DHCPv6 is that all the hosts get the same  
information at the same time, so they're pretty much going to do the  
same thing at the same time. With DHCPv6 address configuration hosts  
will be asking for an address at random times. It would be possible  
for the server to hand out lease times that synchronize the clients,  
but that wouldn't work reliably because there is no control over when  
the clients renew their leases. And it would be undesirable, because  
it's a large amount of traffic at the same time. Worse, this is  
multicast traffic, which is very bad for wireless networks. (Although  
hacks should be possible to reduce this.) But the thing that DHCP  
can't do is go out and tell all the clients about a change that  
occurred between a lease and a renewal.

And of course all this complex stuff (maintaining timers and a fixed  
address for the same host) requires a very solid DHCPv6 server that  
keeps a lot of state. Presumably, this wouldn't be a problem in  
enterprises, but you really don't want to have this as a requirement  
in smaller installations.

>> There are many items passed out in DHCP
>> stateless-autoconfig.

We now have RFC 5006 for DNS server addresses, which is the only thing  
that clients really need, all the other stuff may or may not be  
useful, but doesn't necessarily have to be autoconfigured.

And those so inclined can run stateless autoconfig for address  
assignment and stateless DHCPv6 for "other information" but not  
address assignment.

> basic Appletalk-like zeroconf sites.

Interestingly, IPv6 now has ALL the previously known address  
configuration mechanisms (except old DECNET):

- like IPX: combine router advertised prefix with MAC address
- like Appletalk: combine router advertised prefix with random number
- like old IPv4: manual configuration
- like modern IPv4: DHCP

> Unfortunately we still

RFC 5006.

Note also that the dichotomy between stateless autoconfig and central  
management is an artificial one: you could centrally manage a DHCPv6  
server that gives out prefixes to routers with prefix delegation, and  
then these routers advertise those prefixes using stateless  
autoconfig. I tried this three years ago with iffy DHCPv6  
implementations and a Cisco router, and I was very impressed with how  
well it worked. The router even copies the lease time in the RA  
lifetimes so the change happens at the correct moment.

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Aug 2008 11:52:47 +0100

As someone running a dual-stack v6 enterprise (smallish), I think I
agree with everything written in the last few posts.

Brian says that enterprises will want DHCPv6, for the reasons Dale says
(SLAAC being 'distasteful' and the complexity of privacy addresses), but
also DHCP is the model that admins are comfortable with today, and change
is always viewed warily.   Admins will believe that DHCP provides an easier
way to tie addresses to users.

I agree with Brian that the key thing about RFC4192 is that end systems
can live happily in a multiaddressed state during a 'graceful' renumbering
event, no need for that flag day cutover.   But as Eliot says, the
complexity isn't in the end systems, it's in the other devices in the
network, which is where we need some level of automation as described
by Iljitsch.   In the past, Router Renumbering was suggested, but there
were a number of problems with that.

I think also that network management/monitoring tools need to be enhanced
to understand renumbering events, e.g. perhaps to detect if certain hosts
are not in the correct phase of RFC4192.   The event could ideally be 
triggerable and configurable from such a tool.   But that implies the
tool also drives DNS scripts, firewall configurations, etc too.

-- 
Tim

---

From: Bruce Curtis <[email-masked]>
Date: Tue, 26 Aug 2008 08:53:57 -0500

> vs. DHCP?  Current dual-stack site admins would be especially  

  When we enabled IPv6 on our whole campus network the main issue was  
that autoconfig did not give our security folks a log of the MAC to IP  
mapping over time.  So we set up some scripts to grab the Neighbor  
Cache periodically as a temporary solution until we implemented  
DHCPv6.  I've talked to several other universities who have either  
implemented equivalent scripts (even earlier than us) or plan to as  
they implement IPv6.

  Looking more closely at DHCPv6 our Neighbor Cache scripts may be  
more permanent than we planned since the client id in DHCPv6 may be  
based on the MAC of any interface on the host which is different than  
DHCP in IPv4 where the client id was based on the MAC of the interface  
the DHCP request came from.  It looks like there is a reason for the  
difference, I just didn't spot the difference earlier.
  Any MAC address on the machine will help our security folks identify  
a machine but on the practical side we find it quite useful to block  
the MAC addresses of hosts, for example if they are compromised etc.   
And for the MAC blocking to be successful we need to have the correct  
MAC that a host uses on a given subnet.

  Longer term, security aside, we also will want DHCPv6 for more  
purely network administration reasons.  We have had devices from unix  
workstations to lightweight Access Points and VoIP phones that learn  
extra info via DHCP.  The workstations learned the address of tftp  
servers, the APs the addresses of controllers and the phones several  
different IP addresses.  The APs now have at least two other methods  
of learning the IPs of the controllers and long term it is possible  
that phones would provide options other than DHCP also.
  But in addition to learning extra addresses we have also used the  
vendor class info to assign devices to different IP pools based on the  
vendor.

  I expect that just as we will have both IPv4 and IPv6 in our campus  
for quite a while we will likely be using both DHCPv6 and autoconfig  
for quite a while (especially with vendors like Apple saying they have  
no plans to implement DHCPv6).

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Aug 2008 08:30:42 -0700

Iljitsch,
 
>hacks should be possible to reduce this.)

DHCPv6 relays can be provisioned with the unicast addresses
of servers, and clients can contact relays via link-local
multicast. So, it is not necessarily true that there will
always be undesireable levels of multicast traffic when
the correct configurations are used (no hacks required).

Fred
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 26 Aug 2008 17:45:41 +0200

On 26 aug 2008, at 17:30, Templin, Fred L wrote:

> clients can contact relays via link-local
> multicast.

That is exactly the problem. On 802.11 networks multicasts are sent at  
a very low speed for compatibility and because there are no ACKs for  
multicasts, so they use up a lot of airtime/bandwidth.

The hack that I was talking about would be for accesspoints to not  
repeat multicasts from clients on the wireless network. (I'm guessing  
this would make the network at IETF meetings a lot faster during  
plenaries.)

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Aug 2008 08:55:38 -0700

>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:[email-masked]] 
>Sent: Tuesday, August 26, 2008 8:46 AM
>To: Templin, Fred L
>Cc: Routing Research Group
>Subject: Re: [RRG] Consensus check: renumbering - missing dimension
>

Who says the client has to contact the relay over an 802.11
network? Who says the client even has to reside on a different
physical platform than the relay? AFAICT, an internal virtual
link can service a client's requests through relay just the
same as for an external physical link.

Fred