Subject: IPv6 Router Advertisement Option for NTP Server Configuration

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 20 Dec 2011 06:54:01 +0530

Hi,

We have posted a new draft that extends Router Advertisements to include information about the one or more NTP servers present in the network. This is useful where the delays in acquiring server addresses and communicating with the servers are critical (mobile environment for example). 

http://www.ietf.org/internet-drafts/draft-bcd-6man-ntp-server-ra-opt-00.txt 

Would be great to get some feedback from the WG.

We will also be soliciting comments from the NTP and the TICTOC WGs.

Cheers, Manav

---

From: Doug Barton <[email-masked]>
Date: Wed, 21 Dec 2011 10:37:58 -0800

On 12/19/2011 5:24 PM, Bhatia, Manav (Manav) wrote:
> Hi,
> 
> We have posted a new draft that extends Router Advertisements to
> include information about the one or more NTP servers present in the
> network. This is useful where the delays in acquiring server
> addresses and communicating with the servers are critical (mobile
> environment for example).

Sort of surprised that no one else has responded so far, but I'll bite.
Quite simply, "no." Slightly less simply, "use DHCP since that's what
it's for."

I'm happy to expound on the evils of "camel's nose already too far under
the tent," etc.

Doug

-- 

		[^L]

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Dec 2011 08:44:59 +1300

> I'm happy to expound on the evils of "camel's nose already too far under

There is of course a broader issue here, illustrated by the endless loop
over in MIF about draft-ietf-mif-dhcpv6-route-option.

What is the intended scope of the RA mechanism?

I was a strong proponent of standardising the DNS server option
in RA, because it is an absolute requirement for even the most
minimal host to get onto the Internet. But I am also a strong
proponent of -dhcpv6-route-option, because it seems clear that
more complex environments will inevitably require the extensibility
that comes with DHCPv6.

I think we need a standards track document that defines the maximum
scope of the RA mechanism once and for all. Personally I would
probably freeze it where it is today, but we need a reasoned
architectural decision about this.

   Brian

---

From: Doug Barton <[email-masked]>
Date: Wed, 21 Dec 2011 12:22:31 -0800

> over in MIF about draft-ietf-mif-dhcpv6-route-option.

... or the endless loop of "we need DNS info in RA" until it finally got
adopted.

> more complex environments will inevitably require the extensibility

So, expound it is. :)

When I first got interested in IPv6 protocol work back in 2000 or so I
was curious about this "RA" thing. Given that DHCP was already widely
deployed and successful in the IPv4 world I wondered why such a thing
was necessary/useful.* I was told at the time that a key feature of IPv6
was going to be the ability to bring "dumb" devices onto the network
that only needed to be addressable (light switches were a commonly used
example). The RA mechanism was perfect for this as it involved no state,
and anything that needed to be even slightly "smart" would use DHCPv6.
As much as I was dubious about it at the time, I accepted that
explanation at face value.

Then someone realized that RA was great for getting a thing on the
network, but at that point the thing wasn't really all that useful. So
the logical next step was to extend RA to allow for sending out
resolving DNS info. The point I (and others) tried to make at the time
went something like this (I will use the first person so as to take 100%
of the blame, but that's not meant to exclude the others who made
significant contributions to the line of argument that I support):

Me:	Um, if it's not a dumb device, why can't it use DHCP?
Them:	DHCP is too heavy-weight. We just need one more piece of
information provided by RA and then we'll have a fully-functional client
without the need for DHCP at all, isn't that great!
Me:	Um, well, I see what you're saying, but doesn't that sort of open
the door for adding more things down the road? And as both a system
administrator and an operating system developer I have serious concerns
about having to support 2 different host configuration protocols. It
will inevitably lead to problems, and ...
Them:	No no no, don't be silly! We JUST want to add this ONE little
thing. After that we promise, no more!
Me:	I just think it's a bad precedent. Besides, adding only the
nameserver info isn't enough, you also need the domain and/or search
string to make it useful.
Them:	*snap* Oh, right! Thanks for pointing that out. Ok, we'll add that
too, but after that, NO MORE. I PROMISE!
Me:	Um ....

> architectural decision about this.

Given that using RA for DNS info isn't widely deployed yet, I would vote
for rolling RA back to its originally designed purpose, THEN saying "no
more, really, I mean it." But I doubt that either of those options will
be successful. I would be ecstatic to be proven wrong however.

Doug

* I realize that when RA was first conceived DHCP wasn't that well
established yet, and furthermore I understand that some people disagree
on how well established it was even as late as 2000. My experience at
the time was that DHCP was already widely used in both the SOHO and
large enterprise markets. In any case I don't think anyone can argue
that in the last 11 years it hasn't been firmly established. Failure to
recognize why DHCP is popular, and why RA isn't, is a bug in the
protocol development process.

-- 

		[^L]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Dec 2011 11:07:33 +1300

Doug,

Excuse front posting, but I think there's another aspect to this,
which is that the Service Location Protocol (RFC 2165) was
standardised in 1997, when DHCP was still a newcomer, and it
offers a multicast service discovery mechanism that doesn't
need *any* central server (the SLP Directory Agent is optional).

A combination of basic RA plus directory-less SLP would be
necessary and sufficient for small unmanaged networks, I think.

Regards
   Brian

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 22 Dec 2011 05:22:10 +0530

Hi Doug,
 
> Quite simply, "no." Slightly less simply, "use DHCP since 
> that's what it's for."
> 

I wish it were this simple.

Different operators have different requirements and preferences based on their environments. I have seen deployments where SLAAC is much more useful than DHCPv6. I've seen deployments where DHCPv6 is needed. So both have a place and we should let the operators decide what they want to use. Environments with 4 to 20 devices in them (small businesses) may not want the complexity of setting up a central server. Those environments are probably more suited for SLAAC.

We have heard customers asking SLAAC to be extended to support NTP, "boot-file", "next-server" and a few other things that are currently only available with DHCP. 

Currently, operators need to use both SLAAC and DHCP to run their networks. This is far from ideal. Far better for organizations to look at 2 complete solutions and pick the solution that works best for them in their environment.

Today, we can get NTP server information only with DHCP. DHCP only works after RAs have been processed. In some environments (mobile IPv6) delays in acquiring NTP and other servers information is critical and waiting for DHCP to come up is NOT an ideal solution.

Cheers, Manav

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 21 Dec 2011 19:44:46 -0500

Agree with Manav on the usecases.

Adhoc type of networks, m2m IoT networks and some home networks benefit from SLAAC where DHCP Service may not make sense or may be an overhead to maintain.

-Samita
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, December 21, 2011 3:52 PM
To: Doug Barton
Cc: 6man Mailing List
Subject: RE: IPv6 Router Advertisement Option for NTP Server Configuration

Hi Doug,

Cheers, Manav

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Thu, 22 Dec 2011 06:44:34 +0530

Yes, i agree with Manav and Samita. There are networks where SLAAC is
essential and NTP being a core component, must get extended.

Kam

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 22 Dec 2011 08:19:19 +0100

I agree that one could benefit in some cases from NTP through RA's, however I don't see any info on "cooperation" between DHCPv6 and RA in your draft, i.e. what is you get your NTP through both channels (both RA and DHCPv6) ?  What if content is different on these 2 channels ?  What if (if received on both channels) the content of one of them is not available anymore at some point in time ? ...,
Apart from that, we now have DNS support in RA, you're adding NTP, what's next ... ?  If more info gets sent through RA, more clashes are possible in case the info is also present though DHCPv6, hence the more complex it'll get letting them work together.

regs

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hing-Kam (Kam) Lam
Sent: donderdag 22 december 2011 2:15
To: Samita Chakrabarti
Cc: 6man Mailing List
Subject: Re: IPv6 Router Advertisement Option for NTP Server Configuration

Yes, i agree with Manav and Samita. There are networks where SLAAC is essential and NTP being a core component, must get extended.

Kam

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 22 Dec 2011 08:54:35 +0000

>> I agree that one could benefit in some cases from NTP through RA's, however
>> I don't see any info on "cooperation" between DHCPv6 and RA in your draft,
>> i.e. what is you get your NTP through both channels (both RA and DHCPv6) ?
>> What if content is different on these 2 channels ?  What if (if received on both
>> channels) the content of one of them is not available anymore at some point in
>> time ? ...,
[Dacheng Zhang] 
We originally intend to provide a mechanism which is complementary to the solution using DHCP. So basically, we just consider the scenarios where DHCP is not deployed. But your comments are very interesting, we should consider them in the next version of the draft. 
>> Apart from that, we now have DNS support in RA, you're adding NTP, what's
>> next ... ?  
[Dacheng Zhang] 
That is a very good question. Maybe NTP can be the last one, maybe not. I think this issue is worthwhile for us to spend more time on it.

>> case the info is also present though DHCPv6, hence the more complex it'll get
>> letting them work together.
>> 
[Dacheng Zhang] 
If there is already a DHCPv6 server where users can learn where to find a NTP server, then we may not have to provide the NTP server information in RAes. As what I have said above, we expect to provide a way to locate NTP servers when SLAAC is employed.
>> > Adhoc type of networks, m2m IoT networks and some home networks
>> benefit from SLAAC where DHCP Service may not make sense or may be an
>> overhead to maintain.
>> >
>> > -Samita
>> > Different operators have different requirements and preferences based on
>> their environments. I have seen deployments where SLAAC is much more
>> useful than DHCPv6. I've seen deployments where DHCPv6 is needed. So both
>> have a place and we should let the operators decide what they want to use.
>> Environments with 4 to 20 devices in them (small businesses) may not want
>> the complexity of setting up a central server. Those environments are
>> probably more suited for SLAAC.
>> >
>> > We have heard customers asking SLAAC to be extended to support NTP,
>> "boot-file", "next-server" and a few other things that are currently only
>> available with DHCP.
>> >
>> > Currently, operators need to use both SLAAC and DHCP to run their
>> networks. This is far from ideal. Far better for organizations to look at 2
>> complete solutions and pick the solution that works best for them in their
>> environment.
>> >
>> > Today, we can get NTP server information only with DHCP. DHCP only works
>> after RAs have been processed. In some environments (mobile IPv6) delays in
>> acquiring NTP and other servers information is critical and waiting for DHCP to
>> come up is NOT an ideal solution.
>> >
>> > Cheers, Manav
>> >
>> >
>> >
>> >

---

From: Sander Steffann <[email-masked]>
Date: Thu, 22 Dec 2011 10:04:11 +0100

Hi,

> Different operators have different requirements and preferences based on their environments. I have seen deployments where SLAAC is much more useful than DHCPv6. I've seen deployments where DHCPv6…

SLAAC + Stateless DHCPv6. I agree that a central Stateful DHCPv6 server is too complex for such a situation, but come on: a stateless DHCPv6 server is simple….

- Sander

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 22 Dec 2011 09:13:54 +0000

>> -----邮件原件-----
>> 发件人: [email-masked] [mailto:[email-masked]] 代表 Sander
>> Steffann
>> 发送时间: 2011年12月22日 17:04
>> 收件人: Bhatia, Manav (Manav)
>> 抄送: 6man Mailing List
>> 主题: Re: IPv6 Router Advertisement Option for NTP Server Configuration
>> 
>> Hi,
>> 
>> SLAAC + Stateless DHCPv6. I agree that a central Stateful DHCPv6 server is
>> too complex for such a situation, but come on: a stateless DHCPv6 server is
>> simple….
>> 
[Dacheng Zhang] 
But in this case, we still need to deploy a server... If we can use RAs in such environments, even a stateless DHCP server is not necessary. Please correct me if I am wrong or miss anything.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 22 Dec 2011 10:34:18 +0100

Hi,

> But in this case, we still need to deploy a server... If we can use RAs in such environments, even a stateless DHCP server is not necessary. Please correct me if I am wrong or miss anything. 

Depends on how you see 'deploying a server'. Your router can easily perform the stateless DHCPv6 server function. Even tiny CPEs can do that these days, and Cisco has been doing that for ages.

- Sander

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Dec 2011 13:27:04 +0100

And then the next one, and the next one, until packet size is > 1280 and other horror stories begin :-O

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wuyts Carl
> Sent: jeudi 22 décembre 2011 08:19
> To: Hing-Kam (Kam) Lam; Samita Chakrabarti
> Cc: 6man Mailing List
> What if content is different on these 2 channels ?  What if (if received on
> both channels) the content of one of them is not available anymore at some
> point in time ? ...,
> next ... ?  If more info gets sent through RA, more clashes are possible in
> case the info is also present though DHCPv6, hence the more complex it'll
> get letting them work together.
> 
> 
> regs
> 
> Carl Wuyts
> 
> 
> 
> 
> > Adhoc type of networks, m2m IoT networks and some home networks benefit
> from SLAAC where DHCP Service may not make sense or may be an overhead to
> maintain.
> >
> > -Samita
> their environments. I have seen deployments where SLAAC is much more useful
> than DHCPv6. I've seen deployments where DHCPv6 is needed. So both have a
> place and we should let the operators decide what they want to use.
> > We have heard customers asking SLAAC to be extended to support NTP, "boot-
> file", "next-server" and a few other things that are currently only
> available with DHCP.
> >
> acquiring NTP and other servers information is critical and waiting for DHCP
> to come up is NOT an ideal solution.
> >
> > Cheers, Manav
> >
> >
> >
> >

---

From: Brian Haberman <[email-masked]>
Date: Thu, 22 Dec 2011 08:47:53 -0500

Hi Manav,

> We will also be soliciting comments from the NTP and the TICTOC WGs.

So, as co-chair of both NTP and 6MAN, I would ask how this draft differs 
from RFC 5908.

Regards,
Brian

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 22 Dec 2011 19:26:55 +0530

This problem definitely needs to be addressed. However, its not unique to this draft.

The similar problem exists with DNS, similar prefixes, and a lot of other parameters that you can get with both DHCP and RA.

This is debatable but can be argued as a configuration issue as SLAAC and DHCPv6 shouldn't really be providing conflicting information. One could always provide a CLI knob to assign priorities against these.

Cheers, Manav

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wuyts Carl
> Sent: Thursday, December 22, 2011 12:49 PM
> I agree that one could benefit in some cases from NTP through 
> RA's, however I don't see any info on "cooperation" between 
> DHCPv6 and RA in your draft, i.e. what is you get your NTP 
> through both channels (both RA and DHCPv6) ?  What if content 
> is different on these 2 channels ?  What if (if received on 
> both channels) the content of one of them is not available 
> anymore at some point in time ? ..., Apart from that, we now 
> have DNS support in RA, you're adding NTP, what's next ... ?  
> If more info gets sent through RA, more clashes are possible 
> in case the info is also present though DHCPv6, hence the 
> more complex it'll get letting them work together.
> 
> regs
> 
> Carl Wuyts
> 
> 
> 
> 
> Yes, i agree with Manav and Samita. There are networks where 
> SLAAC is essential and NTP being a core component, must get extended.
> 
> Kam
> 
> > Adhoc type of networks, m2m IoT networks and some home 
> networks benefit from SLAAC where DHCP Service may not make 
> sense or may be an overhead to maintain.
> >
> > -Samita
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Bhatia, Manav (Manav)
> that's what 
> > Different operators have different requirements and 
> preferences based on their environments. I have seen 
> deployments where SLAAC is much more useful than DHCPv6. I've 
> seen deployments where DHCPv6 is needed. So both have a place 
> and we should let the operators decide what they want to use. 
> Environments with 4 to 20 devices in them (small businesses) 
> may not want the complexity of setting up a central server. 
> Those environments are probably more suited for SLAAC.
> >
> > We have heard customers asking SLAAC to be extended to 
> support NTP, "boot-file", "next-server" and a few other 
> things that are currently only available with DHCP.
> >
> > Currently, operators need to use both SLAAC and DHCP to run 
> their networks. This is far from ideal. Far better for 
> organizations to look at 2 complete solutions and pick the 
> solution that works best for them in their environment.
> >
> > Today, we can get NTP server information only with DHCP. 
> DHCP only works after RAs have been processed. In some 
> environments (mobile IPv6) delays in acquiring NTP and other 
> servers information is critical and waiting for DHCP to come 
> up is NOT an ideal solution.
> >
> > Cheers, Manav
> >
> >
> >
> >

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Dec 2011 08:56:34 -0500

> Depends on how you see 'deploying a server'. Your router can easily perform the stateless DHCPv6 server function. Even tiny CPEs can do that these days, and Cisco has been doing that for ages.

Right. To me, this (a stateless DHCPv6 server function in the router device) is 
what this draft has to compete against. The authors would have to demonstrate a 
use case where this is not acceptable/feasible/sufficient.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 22 Dec 2011 19:29:09 +0530

Hi Brian,

5908 uses DHCPv6. We're extending RAs to advertise the NTP info.

Cheers, Manav 

> Behalf Of Brian Haberman
> Sent: Thursday, December 22, 2011 7:18 PM
> To: [email-masked]
> > network. This is useful where the delays in acquiring 
> server addresses 
> > and communicating with the servers are critical (mobile environment 
> > for example).
> >
> > 
> So, as co-chair of both NTP and 6MAN, I would ask how this 
> draft differs from RFC 5908.
> 
> Regards,
> Brian
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 22 Dec 2011 09:24:30 -0500

> 5908 uses DHCPv6. We're extending RAs to advertise the NTP info.

I guess it is a little too early and I did not ask my question clearly 
enough.

Does this RA-based approach provide the exact same information as the 
RFC 5908 DHCP option?  Less info?  More info?

Have you considered simply using the multicast-based NTP server 
discovery in environments where DHCP is not available or providing NTP 
information?

Regards,
Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 22 Dec 2011 14:58:24 +0000

On 22. Dec 2011, at 14:24 , Brian Haberman wrote:

> I guess it is a little too early and I did not ask my question clearly enough.
> 
> Does this RA-based approach provide the exact same information as the RFC 5908 DHCP option?  Less info?  More info?
> 
> Have you considered simply using the multicast-based NTP server discovery in environments where DHCP is not available or providing NTP information?

Just seeing the discussion...

+1 for just using MC NTP.  Even just ff02::101 is great for a lot of use
cases already.  Almost wonder if it should be a lose requirement for v6ops
and the CPEs...  Of course more problematic in large campus networks but
configuring all the services on all the routers for RA there is not what
you really want either.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 22 Dec 2011 10:34:17 -0500

On Dec 21, 2011, at 6:52 PM, Bhatia, Manav (Manav) wrote:

> Different operators have different requirements and preferences based on their environments.

Yes.

> I have seen deployments where SLAAC is much more useful than DHCPv6. I've seen deployments where DHCPv6 is needed. So both have a place and we should let the operators decide what they want to use. Environments with 4 to 20 devices in them (small businesses) may not want the complexity of setting up a central server.

I have a (home) network with 4 to 20 (actually, looking it is more like 60) devices. I don't want the complexity of setting up a central server. Oh! Wait a sec. I didn't set up a central server, the same device that does SLAAC also does DHCPv6. Convenient, huh? Almost like someone was planning ahead.

> We have heard customers asking SLAAC to be extended to support NTP, "boot-file", "next-server" and a few other things that are currently only available with DHCP. 

Yup. 
I'd also like to hand out WINS servers and workgroup name and a proxy server and a log server and a hostname and a preference identifier (so I know which network is "trusted") and a MTU hint and a timezone offset and a walled garden authentication server and a geographical hint so I know how find the nearest Starbucks and local language identifier and base-64 encoded note as to where I left my car keys this time and ...

> Today, we can get NTP server information only with DHCP. DHCP only works after RAs have been processed. In some environments (mobile IPv6) delays in acquiring NTP and other servers information is c…

'tis not ideal that I cannot find my car keys, especially when I'm already late for work. Where's my RA provided key hint option, please?

> Cheers, Manav

Cheerio,
  W

P.S: I have not had my morning coffee - this email might sound more pissy than I intended...

---

From: Doug Barton <[email-masked]>
Date: Thu, 22 Dec 2011 23:56:59 -0800

Yeah, and/or the recently approved multicast DNS draft. Personally I
like DHCP, but I'm not saying it's the only answer.

What I *am* saying is that extending RA is always the *wrong* answer.

Doug

-- 

		[^L]

---

From: Doug Barton <[email-masked]>
Date: Fri, 23 Dec 2011 00:19:53 -0800

On 12/21/2011 15:52, Bhatia, Manav (Manav) wrote:
> Hi Doug,
> 
>> 
>> Sort of surprised that no one else has responded so far, but I'll
>> bite. Quite simply, "no." Slightly less simply, "use DHCP since 
>> that's what it's for."
>> 
> 

Well good news for you then, it IS that simple. :)

> Different operators have different requirements and preferences based
> on their environments. I have seen deployments where SLAAC is much
> more useful than DHCPv6. I've seen deployments where DHCPv6 is
> needed. So both have a place and we should let the operators decide
> what they want to use.

Eloquent words, but they miss a central point. There is a huge cost
involved in implementing the same configuration information through
different mechanisms. Over strenuous objections DNS information was
added to RA and we're still dealing with the fallout. There are also
costs in the development and deployment areas. It's not like we can just
wave a magic wand and make all possibilities available to all the
players without any work involved.

> Environments with 4 to 20 devices in them
> (small businesses) may not want the complexity of setting up a
> central server. Those environments are probably more suited for
> SLAAC.

Show me the small business that doesn't already have a DHCP server baked
into their router/toaster, that doesn't "just work" with near-zero human
interaction.

> "boot-file", "next-server" and a few other things that are currently
> only available with DHCP.

I'm asking for a pony. Hook me up. :)

> networks. This is far from ideal.

This much I agree with.

> Far better for organizations to
> look at 2 complete solutions and pick the solution that works best
> for them in their environment.

Wrong answer. The right answer is for DHCPv6 to be a superset of RA so
that organizations that need more than RA provides only have to run
DHCP. As a free bonus, it's FAR easier to add one knob (default route)
to DHCPv6 than it is to add all features to RA. Extra bonus, the only
hurdles are political, not technical.

> Today, we can get NTP server information only with DHCP. DHCP only
> works after RAs have been processed. In some environments (mobile
> IPv6) delays in acquiring NTP and other servers information is
> critical and waiting for DHCP to come up is NOT an ideal solution.

See above.

Doug

-- 

		[^L]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Dec 2011 13:11:02 +1300

> On 12/21/2011 15:52, Bhatia, Manav (Manav) wrote:

...
>> critical and waiting for DHCP to come up is NOT an ideal solution.

Can you explain why it is so time critical? If the mobile device is
already up and running, it will already have an accurate current clock
time, and can resynch with NTP at its leisure.

If it's booting from cold, it will not be in any MIP session so there
can't be any urgency.

I assume that in any case the mobile will have a preconfigured default
NTP server, by DNS name or even IP address.

   Brian

---

From: Scott Schmit <[email-masked]>
Date: Sat, 24 Dec 2011 09:25:06 -0500

> hurdles are political, not technical.

I agree with your essential point, except to say that for me to be happy
with DHCPv6, I also want to be able to assign an address to a host by
taking some constant bit of information from the host (like, say, a MAC
address) and know that no matter how I reinstall that host, it'll retain
the address I gave it.

As it is today, to use DHCPv6 the way I want, I must first have my host
get an IP (the wrong one), figure out what DUID it used, and reconfigure
my server to give it the one I want it to have. With RA, I don't assign
the address, but to know what it is, I just look up its MAC address and
I'm done. With DHCPv4, I look up its MAC address, add it to my server
configuration and I'm done.

I don't really care if it's a MAC address per se, but I don't want to
have to deal with DUID change because of OS reinstallation, change of
client software, dual-boot, removal & re-adding of the connection
definition, etc. I can think of reasons why it might be nice to have
different DUIDs for different OS's, so I don't object to the option, but
in most cases the current spec hurts (me) more than it helps.

-- 
Scott Schmit

---

From: [email-masked]
Date: Sat, 24 Dec 2011 15:53:44 +0100 (CET)

> in most cases the current spec hurts (me) more than it helps.

I'm amazed at how the DUID was supposed to be "better than" (more
stable than) a MAC address - and therefore the MAC address wouldn't
be needed), but ends up being worse in too many cases. 

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 25 Dec 2011 15:06:11 +0100

On Dec 23, 2011 8:57 AM, "Doug Barton" <[email-masked]> wrote:
<snip>
> What I *am* saying is that extending RA is always the *wrong* answer.

Yes it is. Keep RA simple and lets solve "problems" elsewhere, dhcp is the
current tool.

--- Roger J ---