headers
Internet-Drafts | 1 Aug 2003 21:27
Picon
Favicon

I-D ACTION:draft-ietf-dhc-unused-optioncodes-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Unused DHCP Option Codes
	Author(s)	: R. Droms
	Filename	: draft-ietf-dhc-unused-optioncodes-05.txt
	Pages		: 11
	Date		: 2003-8-1
	
Prior to the publication of RFC2489 (which was updated by RFC2939),
several option codes were assigned to proposed DHCP options that were
subsequently never used. This document lists those unused option
codes and directs IANA to make these option codes available for
assignment to other DHCP options in the future.
The document also lists several option codes that are not currently
documented in an RFC but should not be made available for
reassignment to future DHCP options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-unused-optioncodes-05.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jitesh N Verma | 2 Aug 2003 15:06
Picon

Source address and source port problem in DHCP server

Hi all,
Please read care fully, since the following text is 
bit confusing.

Background:
I have come across a relay agent (CISCO router),
which checks the source IP address of the server's
reply packet against the destination IP address
of the relayed request packet and discards the
reply packet if they do not match. 
If a DHCP relay agent relays a request to an alias
IP address (e.g.lan0:1 - 1.1.1.2), HP DHCP server
replies with primary IP address (lan0 - 1.1.1.1) as
the source IP address. If there is no alias IP address
configured for an interface, the DHCP server works fine.

Question:
Can somebody tell me if checking of the source address
of the reply packet with the destination address of the
relayed request packet by a DHCP relay agent OK? RFC
does not say anything on this issue. I want to know
who is not comploying with the RFC? Relay? Or the
server?

While trying to fix the source address problem in
DHCP server, I ran into similar problem with the
source port. I want to know if any implemettaion
of DHCP relay agent checks for the source port of
the reply packet with the destination port of the
relayed request packet.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ted Lemon | 2 Aug 2003 19:36

Re: Source address and source port problem in DHCP server

On Saturday 02 August 2003 08:06, Jitesh N Verma wrote:
> Can somebody tell me if checking of the source address
> of the reply packet with the destination address of the
> relayed request packet by a DHCP relay agent OK? RFC
> does not say anything on this issue. I want to know
> who is not comploying with the RFC? Relay? Or the
> server?

If the RFC doesn't say that the relay agent should do this (and it does not) 
then the relay agent shouldn't do it.   This is a completely wrong to thing 
do, because it breaks interoperability by imposing a requirement on the 
server that is not stated in the protocol specification.   I suspect it's a 
bug in some software version that results from some feature they've added, 
rather than something they have decided they ought to do in general.
Permalink | Reply | 4 comments |
headers
Jitesh N Verma | 4 Aug 2003 08:15
Picon

RE: Source address and source port problem in DHCP server

Hi all,
Ted, thanks a lot for your reply.
I expect some more list members to give their
opinion and then we should build a consensus
on this kind of issues.

Regards,
Jitesh

-----Original Message-----
From: dhcwg-admin <at> ietf.org [mailto:dhcwg-admin <at> ietf.org]On Behalf Of Ted
Lemon
Sent: Saturday, August 02, 2003 11:06 PM
To: jitesh <at> india.hp.com
Cc: dhcwg <at> ietf.org
Subject: Re: [dhcwg] Source address and source port problem in DHCP
server

On Saturday 02 August 2003 08:06, Jitesh N Verma wrote:
> Can somebody tell me if checking of the source address
> of the reply packet with the destination address of the
> relayed request packet by a DHCP relay agent OK? RFC
> does not say anything on this issue. I want to know
> who is not comploying with the RFC? Relay? Or the
> server?

If the RFC doesn't say that the relay agent should do this (and it does not)
then the relay agent shouldn't do it.   This is a completely wrong to thing
do, because it breaks interoperability by imposing a requirement on the
server that is not stated in the protocol specification.   I suspect it's a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sanjeev Verma | 4 Aug 2003 20:05

Re: Source address and source port problem in DHCP server


Ted Lemon wrote:
> On Saturday 02 August 2003 08:06, Jitesh N Verma wrote:
> 
>>Can somebody tell me if checking of the source address
>>of the reply packet with the destination address of the
>>relayed request packet by a DHCP relay agent OK? RFC
>>does not say anything on this issue. I want to know
>>who is not comploying with the RFC? Relay? Or the
>>server?
> 
> 
> If the RFC doesn't say that the relay agent should do this (and it does not) 
> then the relay agent shouldn't do it.   This is a completely wrong to thing 
> do, because it breaks interoperability by imposing a requirement on the 
> server that is not stated in the protocol specification.   I suspect it's a 
> bug in some software version that results from some feature they've added, 
> rather than something they have decided they ought to do in general.
> 
> 

It is an implementation detail - how to match replies to requests. For 
relay, (xid, mac address, message type)-tuple should be sufficient to 
match replies to requests. But in this case, the relay appears to be 
using (server IP address, port sent out on)-tuple to do either matching 
or additional checking. And that's broken.
   For the sake of completion - under some circumstances, matching 
requests to replies using mac address may also not work. And, if the 
relay is attaching option 82 to relayed requests, that could also effect 
the matching logic in relay.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Droms | 4 Aug 2003 20:13
Picon
Favicon

Re: Source address and source port problem in DHCP server

In general, there is no need to match replies to requests.  One of the 
design principles for DHCP is to avoid the requirement for the relay agent 
to maintain any state about individual DHCP messages.  All of the 
information required by a relay agent to forward the reply to the DHCP 
client is contained in the message itself (client MAC and IP 
address).  Even in the case of option 82, the information needed by the 
relay agent to forward the reply to the correct downstream port is 
contained in option 82 itself.

- Ralph

At 11:05 AM 8/4/2003 -0700, Sanjeev Verma wrote:

>Ted Lemon wrote:
>>On Saturday 02 August 2003 08:06, Jitesh N Verma wrote:
>>
>>>Can somebody tell me if checking of the source address
>>>of the reply packet with the destination address of the
>>>relayed request packet by a DHCP relay agent OK? RFC
>>>does not say anything on this issue. I want to know
>>>who is not comploying with the RFC? Relay? Or the
>>>server?
>>
>>If the RFC doesn't say that the relay agent should do this (and it does 
>>not) then the relay agent shouldn't do it.   This is a completely wrong 
>>to thing do, because it breaks interoperability by imposing a requirement 
>>on the server that is not stated in the protocol specification.   I 
>>suspect it's a bug in some software version that results from some 
>>feature they've added, rather than something they have decided they ought 
>>to do in general.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Lemon | 4 Aug 2003 20:53

Re: Source address and source port problem in DHCP server

On Monday 04 August 2003 13:13, Ralph Droms wrote:
> In general, there is no need to match replies to requests.  One of the
> design principles for DHCP is to avoid the requirement for the relay agent
> to maintain any state about individual DHCP messages.  All of the
> information required by a relay agent to forward the reply to the DHCP
> client is contained in the message itself (client MAC and IP
> address).  Even in the case of option 82, the information needed by the
> relay agent to forward the reply to the correct downstream port is
> contained in option 82 itself.

To expand on this a little, of course there are times when it may be desirable 
to make the relay agent do more than a dumb relay agent would, and in those 
cases it may be necessary to match messages, even though the protocol neither 
needs nor suggests such matching.   As Ralph has said, the way to do this is 
with the relay agent information option.   As Ralph has also said, in general 
the relay agent information option should provide enough of a cache for the 
relay that it doesn't actually need to do message matching - it should be 
able to blindly forward the message to the right place based on the 
information returned by the server in the relay agent information option.

At a minimum, any enhancements that are made in the relay agent that are not 
required by the protocol must do no harm.   They must not break 
interoperability.   What the gentleman from HP has described breaks 
interoperability, so any devices that do this are not in compliance with 
RFC951 or RFC2131.   It would be wrong for the manufacturer of these devices 
to claim compliance with either of these protocols if the devices fail to 
deliver relayed messages that are themselves in compliance with the 
protocols.

Of course, as I say, I suspect this is just a bug, so there's probably no need
(Continue reading)

Permalink | Reply | 0 comments |
headers
yuan zhang | 5 Aug 2003 03:34
Picon
Favicon

fixed address

hi,can use other item to specify a fixed ipaddress to client rather than 
hardaddress?

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail
Permalink | Reply | 0 comments |
headers
Alper Yegin | 5 Aug 2003 20:36

pana-bootstrap-rfc3118


From the DHC WG meeting notes:

    RFC3118 Delayed Authentication Using PANA          H. Tschofenig
    <draft-tschofenig-pana-bootstrap-rfc3118-00.txt>

    This document describes a mechanism for establishing a DHCP SA
    (between client and server) through PANA (assuming PANA is invoked
    before DHCP).  The scenario is:

       * host establishes SA with PANA
       * PAA does key distribution to host and DHCP server
       * host and server use key for authenticated DHCP

    There was some discussion about the mechanism through which the PAA
    would get keying information to the DHCP participants.  The WG
    requested that the draft be revised to provide additional detail,
    and will reconsider the draft after the revisions are published.

Before we produce the next rev of the draft, we'd like to fully understand
what should go in. So, let's continue the discussions from where we left at
the meeting.

Here are the points we discussed at the meeting. We are sure we missed some,
please add...

- How is the DHCP SA key transferred from DHCP relay (PAA) to DHCP server?

  The DHCP architecture already has the concept of carrying client-specific
  data from the dhcp relay to dhcp server after the network access AAA
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Schnizlein | 5 Aug 2003 21:04
Picon
Favicon

Re: pana-bootstrap-rfc3118

At 02:36 PM 8/5/2003, Alper Yegin wrote:

>Before we produce the next rev of the draft, we'd like to fully understand
>what should go in. So, let's continue the discussions from where we left at
>the meeting.

My impression was that the concerns about this draft went much deeper
than editing-in more text could repair.

There is the issue that PANA does not have Security Area endorsement
to be a key-distribution protocol.

There is an irony in that PANA, which was justified as different from
IEEE 802.1X by hosts having IP addresses first (not layer 2), is 
proposed to operate before DHCP, which provides the IP address.

There is (at least) intolerable complexity in the cooperation of
the DHCP relay agent, which does not participate in the client-server
message authentication for which PANA proposes to provide keys.

I thought the consensus was that the WG not take on this work.

John
Permalink | Reply | 8 comments |

Gmane