headers
Erik Nordmark | 3 Feb 2003 21:45
Picon

Re: Re: PD lifetimes


> Yes, *if we want to allow the delegating router to have the ability to
> control the downstream valid and preferred lifetimes*. 

I agree that this "if" is a key question.

But what I don't understand is the semantics of any lifetime
if we decide that the delegating DHCP server should not be able to
control the prefix lifetimes, then what is the purpose of having any
lifetime in the prefix delegation option? Wouldn't it be sufficient to
just have T1/T2 in that case?

> Before going that further, however, I still think it is overkilling
> for the delegating router to have the ability to control the
> downstream lifetimes.  IMO, the requesting router (and the site's
> administrator) should be responsible for such parameters, with one
> trivial constraint: the site lifetimes must not be smaller than the
> lifetimes of each downstream link.

Yes, but the counter argument is for home sites that don't have
an administrator it might make sense to allow the ISP to be able to suggest
or control the lifetimes. Of course, managed sites might be able to override
the lifetimes.

>   1. the requesting router should also have the additional bits (like
>      P and V above),
>   2. (this may be controversial) the lifetimes in router advertisement
>      on each downstream link should be the same as the default of RFC
>      2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT
>      decreasing in real time), as long as Renew/Reply exchanges
(Continue reading)

Permalink | Reply | 2 comments |
headers
Barr Hibbs | 3 Feb 2003 21:50

Review of DHCPv4 Implementation Issues


One of the work items adopted by the DHC Working Group at IETF-55 in Atlanta
was a review of what I'll generically call "implementation issues" faced by
implementors of DHCP clients, servers, and relay agents.

The purpose of this review is to identify areas of the protocol that were:

	1.  not well-specified
	2.  described in a less-than-clear way
	3.  had dubious value or harmful side-effects
	4.  conflicted with other RFCs
	5.  internally inconsistent, that is, conflicted with
	    other sections of the specification
	6.  "difficult" to implement or test for interoperability
	7.  not implemented because of external policies
	8.  "seemed like a good idea" at the time, but are now
	    considered unnecessary, redundant, or wrong

I'm calling on all implementors, developers, and designers to offer their
observations, comments, wishes, anecdotes, and observations so that we may
create a list of problem areas that need resolution before submitting the
RFC for consideration as a full Internet Standard.

Even typographical errors, grammatical mistakes, and organizational issues
are fair game for this purpose.

Thanks in advance for your help.

--Barr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ole Troan | 4 Feb 2003 06:21
Picon
Favicon

Re: questions about prefix-delegation-01

>>> 3. Section 11 of the PD draft says:
>>> 
>>> In some circumstances the requesting router may need verification
>>> that the delegating router still has a valid binding for the
>>> requesting router.  Examples of times when a requesting router may
>>> ask for such verification include:
>>> 
>>> o  The requesting router reboots.
>>> ...
>>> If such verification is needed the requesting router MUST initiate a
>>> Renew/Reply message exchange as described in the section "Creation
>>> and Transmission of Renew Messages" of the DHCP specification [6].
>>> 
>>> I don't see why a Renew/Reply exchange is used, instead of a
>>> Confirm/Reply exchange.  The described situation is very similar to
>>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference
>>> to use a Renew/Reply exchange.  If there is, the PD draft should be
>>> clear on this.
>
>> Yes, I think a Confirm message could be used in this case.
>
> Okay, so do you think the PD draft should be updated by replacing the
> Renew with Confirm?  I personally think it should, because otherwise
> it would be unclear why we had Confirm in the base DHCPv6 spec in the
> first place.

the Confirm message has different semantics. it is used to verify that
a prefix is still on-link, something which restricts it usefulness to
address assignment. the Reply to a Confirm can come from any server,
and there is no requirement that a binding with the server exists.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Senthil Kumar B | 4 Feb 2003 10:43
Picon

Can a DHCPv4 server REPLY to non-standard port.

I heard about cases where a DHCP server like ISC DHCP runs on a
different port (other than the standard port 67). In that Can I assume
the client also run on a selected non-standard port(other than the
standard port 68).

I just wanted to clarify one thing here. When a DHCP server runs on a
non-standard port (may be 1070) and the client is running in (may be
1080, instead of 1071 conventionally), the server should understand the
client's port from the client's request packet and reply to the
port(1071) accordingly.

Will there be any problem if the client runs on a non-standard dynamic
port(varies for different dhcpclients)? One of the problem i could see
is that, the client (may be customized) can request all the IP addresses
and eventually the server will be running out of addresses to assign
(Because, any normal user  can write up a program and send DHCP messages
to acquire all the IP address).

Is this scenario violating the standards and if so how to avoid the
problem ?

Appreciate your help in advance,

Thanks,
Senthil
Permalink | Reply | 6 comments |
headers
Vasu, Vallabhaneni | 4 Feb 2003 14:39
Picon
Favicon

Re: Can a DHCPv4 server REPLY to non-standard port.

Senthil Kumar B wrote:

> I heard about cases where a DHCP server like ISC DHCP runs on a
> different port (other than the standard port 67). In that Can I assume
> the client also run on a selected non-standard port(other than the
> standard port 68).
>
> I just wanted to clarify one thing here. When a DHCP server runs on a
> non-standard port (may be 1070) and the client is running in (may be
> 1080, instead of 1071 conventionally), the server should understand the
> client's port from the client's request packet and reply to the
> port(1071) accordingly.
>
> Will there be any problem if the client runs on a non-standard dynamic
> port(varies for different dhcpclients)? One of the problem i could see
> is that, the client (may be customized) can request all the IP addresses
> and eventually the server will be running out of addresses to assign
> (Because, any normal user  can write up a program and send DHCP messages
> to acquire all the IP address).

This problem can happen even if the client uses the standard ports. All you
need to do is write c code to generate different client id's (MAC or option
61). This issue is  being handled in RFC 3118.

>
>
> Is this scenario violating the standards and if so how to avoid the
> problem ?
>
> Appreciate your help in advance,
(Continue reading)

Permalink | Reply | 5 comments |
headers
JINMEI Tatuya / 神明達哉 | 4 Feb 2003 08:46
Picon

Re: Re: PD lifetimes

>>>>> On Mon, 3 Feb 2003 21:45:55 +0100 (CET), 
>>>>> Erik Nordmark <Erik.Nordmark <at> sun.com> said:

>> Yes, *if we want to allow the delegating router to have the ability to
>> control the downstream valid and preferred lifetimes*. 

> I agree that this "if" is a key question.

> But what I don't understand is the semantics of any lifetime
> if we decide that the delegating DHCP server should not be able to
> control the prefix lifetimes, then what is the purpose of having any
> lifetime in the prefix delegation option? Wouldn't it be sufficient to
> just have T1/T2 in that case?

It is, unless we do not want to control per-prefix lifetime in a
single IA_PD.  (If we remove the notion of per-prefix lifetime, then
we'd clarify the maximum retransmission duration (MRD) of Rebind for
IA_PD accordingly).

>> Before going that further, however, I still think it is overkilling
>> for the delegating router to have the ability to control the
>> downstream lifetimes.  IMO, the requesting router (and the site's
>> administrator) should be responsible for such parameters, with one
>> trivial constraint: the site lifetimes must not be smaller than the
>> lifetimes of each downstream link.

> Yes, but the counter argument is for home sites that don't have
> an administrator it might make sense to allow the ISP to be able to suggest
> or control the lifetimes. Of course, managed sites might be able to override
> the lifetimes.
(Continue reading)

Permalink | Reply | 1 comment |
headers
JINMEI Tatuya / 神明達哉 | 4 Feb 2003 11:00
Picon

Re: questions about prefix-delegation-01

>>>>> On Tue, 04 Feb 2003 05:21:20 +0000, 
>>>>> Ole Troan <ot <at> cisco.com> said:

>>>> I don't see why a Renew/Reply exchange is used, instead of a
>>>> Confirm/Reply exchange.  The described situation is very similar to
>>>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference
>>>> to use a Renew/Reply exchange.  If there is, the PD draft should be
>>>> clear on this.
>> 
>>> Yes, I think a Confirm message could be used in this case.
>> 
>> Okay, so do you think the PD draft should be updated by replacing the
>> Renew with Confirm?  I personally think it should, because otherwise
>> it would be unclear why we had Confirm in the base DHCPv6 spec in the
>> first place.

> the Confirm message has different semantics. it is used to verify that
> a prefix is still on-link, something which restricts it usefulness to
> address assignment. the Reply to a Confirm can come from any server,
> and there is no requirement that a binding with the server exists.

> for PD we wanted a message exchange to verify that the delegating
> router still has a binding with the requesting router, therefore the
> use of Renew.

Okay, I understand the intention.  However, I still think of a case
where Confirm is more appropriate.  For example, suppose that we have
two upstream "cables", each of which connects to a separate ISP.  Also
suppose that the requesting router has an upstream port.  We first
plug one cable to the upstream port, and then switch to another
(Continue reading)

Permalink | Reply | 6 comments |
headers
JINMEI Tatuya / 神明達哉 | 4 Feb 2003 11:20
Picon

Re: questions about dhcpv6-28

(In the followings, I folded some long lines)

>>>>> On Tue, 28 Jan 2003 12:42:33 -0600, 
>>>>> "Bernie Volz (EUD)" <Bernie.Volz <at> am1.ericsson.se> said:

>> Ralph pointed out to me the possibility of some "magic" between a
>> primary server and a backup server, which allows those servers to be
>> synchronized in real time.  I'm not sure how this is realistic,
>> either, but I'd personally prefer to keep the possibility.

> For DHCPv6 there seems to me a better way to handle things like failover?

> The two standard mechanisms would be:
> 1. Failover like protocol between the two servers
> 2. Redundant backend database

> But, with the large IPv6 addresses, there is another way which I
> think is even better and requires no communication between
> "redundant" servers (well, there is the configuration issues but
> there is no need or minimal need for ongoing communication). The
> idea is as follows:

(snip)

> I wonder whether the DHC WG might take this on - to specify how
> redundant DHCPv6 services could or should be built? I think it will
> be easier than the DHCPv4 failover work and may not require any
> protocol - just a way of working? But, then perhaps this is simply
> left to the server implementers to decide how best to work and
> interoperability between several vendors is not required?
(Continue reading)

Permalink | Reply | 0 comments |
headers
JINMEI Tatuya / 神明達哉 | 4 Feb 2003 10:25
Picon

Re: questions about dhcpv6-28

>>>>> On Wed, 29 Jan 2003 11:23:07 -0500, 
>>>>> Ralph Droms <rdroms <at> cisco.com> said:

>> Actually, Section 15.6 *seems to* address the case.  It says:

(snip)

>> However, there should be a wording problem.  I guess the sentence
>> actually intended to be:
>> 
>> Servers MUST discard any received Renew message that fails to meet
>> ^^^^^^^^
>> any of the following conditions:

> Excellent point; thanks for catching that goof.

> While this check is defined in section 15.6, would it be helpful
> to add a reference in section 18.1.3 explaining the reason for
> that constraint?

Hmm, I'm not sure if this case is that special, but the explanation
itself would surely be helpful.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp
Permalink | Reply | 0 comments |
headers
Bud Millwood | 4 Feb 2003 16:06

Re: Can a DHCPv4 server REPLY to non-standard port.

On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote:

> This problem can happen even if the client uses the standard ports. All you
> need to do is write c code to generate different client id's (MAC or option
> 61). This issue is  being handled in RFC 3118.

We respond to the source port the client is using, but allow the administrator 
to override this at the server. It seemed like a bad idea to respond to a 
fixed port if no communication had been initiated from that port.

The best way to handle spoofing today, to my knowledge, is to use the trusted 
values found in option 82 for identifying the client. If your server supports 
resource limiting using option 82, and your relay agents support option 82, 
you should be fine.

Otherwise, some sort of pre-registration works, although that's a bit of a 
pain to manage.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:budm <at> weird-solutions.com
Permalink | Reply | 4 comments |

Gmane