On 05/27/2011 17:52, Mark Smith wrote:
Hi Doug,
On Thu, 26 May 2011 15:47:04 -0700
Doug Barton wrote:
On 05/26/2011 15:03, Mark Smith wrote:
Exactly. That's the problem. If you know you can't or aren't very
likely to be able to relay DHCP options to customer's end-nodes, you
don't bother sen
Hi Doug,
On Thu, 26 May 2011 15:47:04 -0700
Doug Barton wrote:
> On 05/26/2011 15:03, Mark Smith wrote:
> > Exactly. That's the problem. If you know you can't or aren't very
> > likely to be able to relay DHCP options to customer's end-nodes, you
> > don't bother sending them. The myriad of DHCP
Earlier Thomas Narten wrote in part:
> Let me ask a question. In IPv4, for typical SOHO routers, do they
> support DHCP relay agent functionality? (My guess is no.)
Small office routers, such as the one in my garage,
generally include DHCP relay agent capability and
also have DHCP server capabil
Brian Haberman wrote:
> > In IPv6, what will the "typical SOHO router" look like, though? Same
> > NAT functionality as IPv4? And if not, is there an automatic way of
> > configuring this SOHO router for any possible DHCP relay function?
>
> What about a situation where rather than using DHCP rel
Barbara - sorry, I wasn't clear. I think we're in agreement. The router at
the edge of a subscriber network does not need the relay function.
There are other network architectures where the relay function is likely to be
needed. It's not clear a single RFC 2119 recommendation is adequate.
-
> +1. It's highly unlikely that an SP wants to field DHCPv6
transactions
> from all the devices in a subscriber network. We have adequate
> mechanisms in place to get delegated prefixes and other config
> information to the DHCPv6 server in the subscriber network without the
> DHCPv6 relay functi
+1. It's highly unlikely that an SP wants to field DHCPv6 transactions from
all the devices in a subscriber network. We have adequate mechanisms in place
to get delegated prefixes and other config information to the DHCPv6 server in
the subscriber network without the DHCPv6 relay function.
I
I'm unaware of any member of the mass market community (which accounts
for a whole lot of "nodes" and "routers") who are asking for or wanting
or expecting DNCP Relay. That's SOHO, Consumer, or the ISPs that serve
them. Are there specialized niches inside these communities that might
like DHCP Rela
Message: 2
Date: Thu, 26 May 2011 16:21:59 -0400
From: Thomas Narten
To:ipv6@ietf.org
Subject: Re: review of draft-ietf-node-req-bis
Message-ID:<201105262021.p4qklx2b020...@cichlid.raleigh.ibm.com>
Going back to this...
Jari Arkko writes:
New text:
12.3. Stateful A
Brian suggestion is what we've seen in all the CPE devices we've had at the
UNH-IOL last two CE Router Events. I haven't seen a CPE/SOHO router act as a
relay agent.
Regards,
Tim
On May 27, 2011, at 8:07 AM, Brian Haberman wrote:
> On 5/26/11 5:46 PM, Manfredi, Albert E wrote:
>> Thomas Narte
On 5/26/11 5:46 PM, Manfredi, Albert E wrote:
> Thomas Narten wrote:
>
>> Let me ask a question. In IPv4, for typical SOHO routers, do they
>> support DHCP relay agent functionality? (My guess is no.)
>>
>> And what about configuring it? It is *not* plug and play, zeroconf
>> magic...
>
> Sinc
On May 26, 2011, at 5:26 PM, Mark Smith wrote:
>
> I think relay should be a MUST. I want to see IPv6 achieve the same
> level of autoconfiguration that previous protocols like Appletalk and
> IPX achieved, which includes automated application/service parameter
> configuration. If the applicatio
On 05/26/2011 15:03, Mark Smith wrote:
Exactly. That's the problem. If you know you can't or aren't very
likely to be able to relay DHCP options to customer's end-nodes, you
don't bother sending them. The myriad of DHCP(v4 and v6) options that
exist that may be useful to an SP are currently of no
Hi Thomas,
On Thu, 26 May 2011 17:30:10 -0400
Thomas Narten wrote:
> Mark Smith writes:
>
> > I think relay should be a MUST.
>
> Let me ask a question. In IPv4, for typical SOHO routers, do they
> support DHCP relay agent functionality? (My guess is no.)
>
I don't think they do, but I'm no
Thomas Narten wrote:
> Let me ask a question. In IPv4, for typical SOHO routers, do they
> support DHCP relay agent functionality? (My guess is no.)
>
> And what about configuring it? It is *not* plug and play, zeroconf
> magic...
Since they are typically NAPTs, I'd say no. They are local DHCP s
Mark Smith writes:
> I think relay should be a MUST.
Let me ask a question. In IPv4, for typical SOHO routers, do they
support DHCP relay agent functionality? (My guess is no.)
And what about configuring it? It is *not* plug and play, zeroconf
magic...
Thomas
--
Hi Thomas,
On Thu, 26 May 2011 16:21:59 -0400
Thomas Narten wrote:
> Going back to this...
>
> Jari Arkko writes:
>
>
> New text:
>
>12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
>
>Because a single DHCP server can support devices on multiple links,
>it is not
Thomas,
> New text:
>
> 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
>
> Because a single DHCP server can support devices on multiple links,
> it is not necessary that every router support DHCPv6 directly.
> However, in order to support DHCPv6 servers on other links, rou
Going back to this...
Jari Arkko writes:
> I have reviewed this draft. In general, this version is well written,
> I agree with the recommendations, and I'd like to thank everyone for
> working on this much needed update. I think the document is ready to
> go to IETF Last Call -- some minor issu
On 26 May 2011, at 12:24 , Bob Hinden wrote:
> I don't have a strong opinion on the specifics of RFC-4429,
> but I want to point out the having sufficient operational
> experience isn't the only criteria for including something
> in node requirements.
I never said it was the ONLY criterion.
It
Ran,
>
> I agree that there is not sufficient operational experience
> with RFC-4429 to justify changing the text in this draft.
>
> If at some future point sufficient operational experience
> is demonstrated, then that experience might justify a change.
> However, we ought not hold up this dra
On 25th May 2011, at 14:33:47 -0400, Thomas Narten wrote in part:
> I personally think the IETF has gotten too formal wanting
> the word MAY when it ends up being stilted English.
I agree with the above -- and I believe that this is a
pretty widespread perspective among IETF participants.
RFC-211
On Wed, 25 May 2011 21:47:04 +0300
Jari Arkko wrote:
> Thomas,
>
> >> Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the
> >> norm than exception today. At the very least, I'd again use the MAY
> >> keyword for this specification. The above sounds almost like
> >> recomm
Thomas,
Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the
norm than exception today. At the very least, I'd again use the MAY
keyword for this specification. The above sounds almost like
recommending to not implement it.
Just how much time does 4429 shave of the r
Hi Jari.
Some quick thoughts.
I'm OK with most of your comments (they are mostly editorial).
I personally think the IETF has gotten too formal wanting the word MAY
when it ends up being stilted English. But that said, the wording
(english) could still be improved as you note.
> > For general p
I have reviewed this draft. In general, this version is well written, I
agree with the recommendations, and I'd like to thank everyone for
working on this much needed update. I think the document is ready to go
to IETF Last Call -- some minor issues below that I think could be
addressed even du
26 matches
Mail list logo
