[dhcwg] Some questions on Relay Agent Encapsulation for DHCPv4

Bharat Joshi <bharat_joshi@infosys.com> Wed, 17 November 2010 14:11 UTC

Return-Path: <bharat_joshi@infosys.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303F83A6900 for <dhcwg@core3.amsl.com>; Wed, 17 Nov 2010 06:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRMU3Hr6FsBI for <dhcwg@core3.amsl.com>; Wed, 17 Nov 2010 06:11:51 -0800 (PST)
Received: from kecgate02.infosys.com (Kecgate02.infosys.com [122.98.14.32]) by core3.amsl.com (Postfix) with ESMTP id 8F5B63A691D for <dhcwg@ietf.org>; Wed, 17 Nov 2010 06:11:45 -0800 (PST)
X-TM-IMSS-Message-ID: <016c52b900005f4d@infosys.com>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 016c52b900005f4d ; Wed, 17 Nov 2010 19:40:27 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Wed, 17 Nov 2010 19:42:27 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Date: Wed, 17 Nov 2010 19:42:27 +0530
Thread-Topic: Some questions on Relay Agent Encapsulation for DHCPv4
Thread-Index: AQHLhmF28M5Dgq3gY0Co9FNjtHG1ww==
Message-ID: <31D55C4D55BEED48A4459EB64567589A107DE29258@BLRKECMBX02.ad.infosys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dhcwg] Some questions on Relay Agent Encapsulation for DHCPv4
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2010 14:11:53 -0000

Hi Ted,

     I finally got some time to go through it. I have come up with following questions and suggestions:

• Whole of abstract is one single sentence. Can we divide them into multiple sentences?

• In abstract, 'more than one relay agent can insert relay agent suboptions into the forwarding chain' -> 'each relay agent can insert or remove required relay agent information while forwarding the DHCP packets'

• Layer 2 address suboption is defined in section 2.3 but its not mentioned that this sub-option is defined for which option. Or can we define global sub-option as well?

• Should we use BOOTRELAYFORWARD and BOOTRELAYREPLY instead of RELAYFORWARD and RELAYREPLY?

• 'ep' and padlen will be added only by the first relay agent. Will it make sense to add these details in relay-segment as a sub-option. This way, this information need not be available in other relay-forward or relay-reply messages. It will also save in some memory if there are multiple relay agents.

• In point 3 of section 3.3, it mention 'End packet' which I think should be 'End option'.

• Why do we need to store pad-len and end-option information? Is it for security purposes? 

• If answer to above is yes, do we need to take care of any data after the 'End option' which is included in the IP header length? If yes, how do we do that?

• Last paragraph of section 3.3 mention sname and file field only. Why is that? Actually speaking, it should not touch any field in DHCP header. Right?

• Something is missing in the last sentence of last paragraph of section 4. 'message from the DHCP server is in response such a message, since it'

• In para 3 of section 4.1, it is not clear what to do with these packets?

• When a new RELAYFORWARD packet is created, what should be done if it exceeds the MTU of the interface on which it needs to be sent?

• In section 4.1.3, first sentence of second para, should not we mention that it must be configurable on per interface basis?

• Can we move the section 4.2.2 after 4.2.4?

• Should we be looking at IP TTL when we create RELAYFORWARD or RELAYREPLY message?

• In section 4.2.1.1, total-length in the IP header will also change. So we will need to recalculate IP header checksum as well.

• In section 4.4.1.2, it does not talk about link selection sub-option. Should we add few lines for the same?

• In section 4.5.1, first para, it says that RA must forward the decapsulated message to IP address in aiaddr. But what if the IP address is a braodcast address. Also should it really do routing while returning the DHCP packets or should it identify the outgoing interface using information available in Relay Segment?

• In section 4.5.1, second para mention 'ARP' which means we are assuming that layer 2 is ethernet while link layer address sub-option can be there for other layer 2 protocols as well. This is mentioned in somewhere else also in this document. Please fix it there as well.

• Second para of section 5.1.1 is one single sentence. It would be great if we can divide this into multiple sentence.

• In section 5.1.2, first para, 'decapsulate relay suboptions' -> 'decapsulate RAIO suboptions'

• Second para of section 5.1.2 defines inner encapsulation. Can we move this to terminology?

• Second last para of section 5.1.2, it uses 'must' for using all suboptions or only one. Is not this too strict? Some DHCP server may want to use first two relay agent options while some other DHCP server may want to use first and last only. So should not we provide more flexibility here?

• Last para of section 5.1.2 is not clear. What are we trying to suggest here?

• In section 5.2, can we remove last part of the sentence "add sends it to the next hop on the way to client'? We anyway explains this below.

• With this relay chaining, do we take care of L2RAs sitting between two L3 RAs?

• In section 5.2.1.1, in second para, DHCP will now add something in Relay Agent suboptions instead of echoing back what it received. Are not we breaking away from current standard here? Do we want to give more emphasis on this here?

• In section 5.3, 'an incoming RAIO from a' -> 'an incoming packet with RAIO from a'

• In section 7, last para, how will relay agent authentication work if L2 RA is available in middle.

Best regards,
Bharat
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***