Bernie Volz (volz | 1 Feb 22:00 2008
Picon

Re: Lease updates after Relay Agent crash

BTW:

We probably made the original DHCPv6 bulk lease query (UDP based) more
complicated than it had needed to be. Part of the reason for that is the
DHCPv6 lease query is more client oriented and also the framework was
there to provide lots of different query types.

I haven't looked into it carefully, but it would seem that for DHCPv4 we
could just add a new lease query message which would be a
"DHCPLEASEQUERYNEXTADDRESS" which would interpret the existing "Query by
IP address" as specifying the last address returned and requesting that
the "next" address be returned. 

This still has the performance (latency) issue of one request/response
per lease, but does avoid having to go to TCP.

Of course, I think the TCP approach used for DHCPv6 would be far
superior as there is one request with many potential responses flowing
over a TCP session.

---

I'm somewhat confused by the "TCP is a problem for a layer 2 device"
statement as so is UDP. Note the following text in RFC 4388:

     o The giaddr MUST be set to the IP address of the requester (i.e.,
       the access concentrator).  The giaddr is independent of the
       "ciaddr" field to be searched -- it is simply the return address
       of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
       message from the DHCP server.
(Continue reading)

Bharat Joshi | 4 Feb 11:35 2008

Re: Lease updates after Relay Agent crash


Bernie,

> We probably made the original DHCPv6 bulk lease query (UDP based) more
> complicated than it had needed to be. Part of the reason for that is the
> DHCPv6 lease query is more client oriented and also the framework was
> there to provide lots of different query types.

I agree.

> I haven't looked into it carefully, but it would seem that for DHCPv4 we
> could just add a new lease query message which would be a
> "DHCPLEASEQUERYNEXTADDRESS" which would interpret the existing "Query by
> IP address" as specifying the last address returned and requesting that
> the "next" address be returned.
> 
> This still has the performance (latency) issue of one request/response
> per lease, but does avoid having to go to TCP.

I think what Pavan is looking at is to get all the lease information for
a given Access Concentrator in one go. This will be useful in avoiding
the data traffic coming to control path which will happen with current
DHCPLEASEQUERY mechanism.

> Of course, I think the TCP approach used for DHCPv6 would be far
> superior as there is one request with many potential responses flowing
> over a TCP session.
> 

Yes. I think Pavan proposed TCP because that takes care of reliability,
(Continue reading)

pavan_kurapati | 4 Feb 17:35 2008

Re: Lease updates after Relay Agent crash


Yes, What I mentioned was to use TCP based bulk lease query in case of Layer 3 Relay Agents where establishing
the TCP connection is possible. Since Layer 2 Relay Agents do not have an IP address and also DHCP Server's
address this option is difficult . The current leasequery mechanism is data driven hence I proposed query
by 'Remote-ID' as a solution to get the lease details reliably without waiting for the traffic to be
initiated. As Bharat pointed out, generating leasequery in Layer 2 Relay Agent itself needs to be defined
which we did in our earlier draft.

Thanks,
Pavan

________________________________________
From: Bharat Joshi
Sent: Monday, February 04, 2008 4:05 PM
To: Bernie Volz (volz)
Cc: pavan_kurapati; DHC WG
Subject: Re: [dhcwg] Lease updates after Relay Agent crash

Bernie,

> We probably made the original DHCPv6 bulk lease query (UDP based) more
> complicated than it had needed to be. Part of the reason for that is the
> DHCPv6 lease query is more client oriented and also the framework was
> there to provide lots of different query types.

I agree.

> I haven't looked into it carefully, but it would seem that for DHCPv4 we
> could just add a new lease query message which would be a
> "DHCPLEASEQUERYNEXTADDRESS" which would interpret the existing "Query by
(Continue reading)

ravi kumar | 6 Feb 08:37 2008
Picon

RFC 3315: Reg Message Retransmisison of Client

I need clarification regarding Message-retransmission of Client, specified in RFC 3315:
14 Reliability of Client Initiated Message Exchanges
 
MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT.
 
Otherwise: if (RT > MRT)
RT = MRT + RAND*MRT

In the above case for MRT >0, at some time during retransmission (RT increases...), MRT no more remains an upper bound, as RT becomes greater than MRT (by the above equality).If muy understanding is correct in this regard, what would be role of MRT parameter in Message Retransmission.
 
Also, the message exchange termination is governed by MRC and MRD, as seen from below lines:
 
MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times.

MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.

If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met.

If both MRC and MRD are zero, the client continues to transmit the message until it receives a response.

Please clarify me in this regard.
regards
Ravi 
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
http://www.ietf.org/mailman/listinfo/dhcwg
Aggarwal Vivek-Q4997C | 7 Feb 09:15 2008

RFC 4030

Hi

 

Does anybody have information that whether ISC – DHCP supports RFC 4030 and how DHCP Server can allocate secure IP Address to the client

 

Regards

Vivek Aggarwal

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
http://www.ietf.org/mailman/listinfo/dhcwg
ravi kumar | 7 Feb 10:32 2008
Picon

Re: RFC 3315: Reg Message Retransmisison of Client

<Resending the mail, as there is no Reponse>
Can someome please respond to the mail!
 
regards
Ravi
On Feb 6, 2008 1:07 PM, ravi kumar <ravikumar.lrk <at> gmail.com> wrote:
I need clarification regarding Message-retransmission of Client, specified in RFC 3315:
14 Reliability of Client Initiated Message Exchanges
 
MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT.
 
Otherwise: if (RT > MRT)
RT = MRT + RAND*MRT

In the above case for MRT >0, at some time during retransmission (RT increases...), MRT no more remains an upper bound, as RT becomes greater than MRT (by the above equality).If muy understanding is correct in this regard, what would be role of MRT parameter in Message Retransmission.
 
Also, the message exchange termination is governed by MRC and MRD, as seen from below lines:
 
MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times.

MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.

If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met.

If both MRC and MRD are zero, the client continues to transmit the message until it receives a response.

Please clarify me in this regard.

regards
Ravi 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
http://www.ietf.org/mailman/listinfo/dhcwg
Robert Elz | 7 Feb 12:11 2008
Picon

Re: RFC 3315: Reg Message Retransmisison of Client

    Date:        Thu, 7 Feb 2008 15:02:00 +0530
    From:        "ravi kumar" <ravikumar.lrk <at> gmail.com>
    Message-ID:  <adf2a3a0802070132r1f9d4a3ft5cce0802ba7ea41a <at> mail.gmail.com>

  | <Resending the mail, as there is no Reponse>
  | Can someome please respond to the mail!

I am guessing you got no response (aside from it being only 24 hours,
which is a bit short to panic!) because no-one really understands what
your problem is.

I'm no expert on this, so I'm going to guess at what your issue is
(if I'm wrong, then you can explain better, and then perhaps someone
else will reply) - or if I'm right in the guess, but my explanation is
wrong, someone who does know the right answer might then be able to
give a better response.

  | > I need clarification regarding Message-retransmission of Client, specified
  | > in RFC 3315:
  | > *14** Reliability of Client Initiated Message Exchanges*

I suspect that your problem is all in the way you're interpreting the
the following sentence ...

  | > MRT specifies an upper bound on the value of RT

and that you are prehaps reading "specifies" as if it said "is".

Then, when you see ...

  | >          RT = MRT + RAND*MRT

MRT can't be the upper bound, as RT is bigger (perhaps).   But
"specifies" != "is", rather it means "tells you how to work out"
which is what happens here.

Once RT has become bigger than MRT, further values of RT are based
solely upon the value of MRT, and no longer depend upon the previous
RT value, and MRT doesn't change, so we have an upper bound upon RT
(it gets no larger than a bit bigger than MRT)

  | > Also, the message exchange termination is governed by MRC and MRD, as seen
  | > from below lines:

Yes, that all looks very clear to me.

  | > Please clarify me in this regard.

Clarify what?

RT (as limited by MRT) says how long to wait between retransmits.
MRC and MRD (in combination) say when you should stop retransmitting
and give up.

Is this the question, and does this answer help?   (And to others, did
I misrepresent the way it works?)

kre
ravi kumar | 7 Feb 12:46 2008
Picon

Re: RFC 3315: Reg Message Retransmisison of Client


Thanks kre for the Reply. You have answered my question !
regards
Ravi
On Feb 7, 2008 4:41 PM, Robert Elz <kre <at> munnari.oz.au> wrote:
   Date:        Thu, 7 Feb 2008 15:02:00 +0530
   From:        "ravi kumar" <ravikumar.lrk <at> gmail.com>
   Message-ID:  <adf2a3a0802070132r1f9d4a3ft5cce0802ba7ea41a <at> mail.gmail.com>

 | <Resending the mail, as there is no Reponse>
 | Can someome please respond to the mail!

I am guessing you got no response (aside from it being only 24 hours,
which is a bit short to panic!) because no-one really understands what
your problem is.

I'm no expert on this, so I'm going to guess at what your issue is
(if I'm wrong, then you can explain better, and then perhaps someone
else will reply) - or if I'm right in the guess, but my explanation is
wrong, someone who does know the right answer might then be able to
give a better response.


 | > I need clarification regarding Message-retransmission of Client, specified
 | > in RFC 3315:
 | > *14** Reliability of Client Initiated Message Exchanges*

I suspect that your problem is all in the way you're interpreting the
the following sentence ...

 | > MRT specifies an upper bound on the value of RT

and that you are prehaps reading "specifies" as if it said "is".

Then, when you see ...

 | >          RT = MRT + RAND*MRT

MRT can't be the upper bound, as RT is bigger (perhaps).   But
"specifies" != "is", rather it means "tells you how to work out"
which is what happens here.

Once RT has become bigger than MRT, further values of RT are based
solely upon the value of MRT, and no longer depend upon the previous
RT value, and MRT doesn't change, so we have an upper bound upon RT
(it gets no larger than a bit bigger than MRT)

 | > Also, the message exchange termination is governed by MRC and MRD, as seen
 | > from below lines:

Yes, that all looks very clear to me.

 | > Please clarify me in this regard.

Clarify what?

RT (as limited by MRT) says how long to wait between retransmits.
MRC and MRD (in combination) say when you should stop retransmitting
and give up.

Is this the question, and does this answer help?   (And to others, did
I misrepresent the way it works?)

kre


_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
http://www.ietf.org/mailman/listinfo/dhcwg
rfc-editor | 8 Feb 00:33 2008

RFC 5107 on DHCP Server Identifier Override Suboption


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5107

        Title:      DHCP Server Identifier Override Suboption 
        Author:     R. Johnson, J. Jumarasamy,
                    K. Kinnear, M. Stapp
        Status:     Standards Track
        Date:       February 2008
        Mailbox:    raj <at> cisco.com, 
                    jayk <at> cisco.com, 
                    kkinnear <at> cisco.com,  mjs <at> cisco.com
        Pages:      7
        Characters: 14837
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dhc-server-override-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5107.txt

This memo defines a new suboption of the DHCP relay information
option that allows the DHCP relay to specify a new value for the
Server Identifier option, which is inserted by the DHCP Server.  This
allows the DHCP relay to act as the actual DHCP server such that
RENEW DHCPREQUESTs will come to the relay instead of going to the
server directly.  This gives the relay the opportunity to include the
Relay Agent option with appropriate suboptions even on DHCP RENEW
messages.  [STANDARDS TRACK]

This document is a product of the Dynamic Host Configuration
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...
Ralph Droms | 9 Feb 23:03 2008
Picon

dhc WG scheduling for IETF 71

dhc WG is scheduled to meet Mon PM.  Any conflicts?

MONDAY, March 10, 2008
1520-1720 Afternoon Session II
Breakout Room	INT	tictoc	Timing over IP Connection and Transfer of Clock
Breakout Room	INT	dhc	Dynamic Host Configuration WG
Breakout Room	OPS	opsarea	Operations & Management Area Open Meeting
Breakout Room	RAI	ecrit	Emergency Context Resolution with Internet  
Technologies WG
Breakout Room	RTG	forces	Forwarding and Control Element Separation WG
Breakout Room	RTG	sidr	Secure Inter-Domain Routing WG
Breakout Room	TSV	ippm	IP Performance Metrics WG

Gmane