IETF Logo Mail Archive

[dhcwg] Reg. Use of Link-Address Field for DHCPv6

"Anup Kumar Vasudevan (anuvasud)" <anuvasud@cisco.com> Fri, 14 September 2012 07:44 UTC

Return-Path: <anuvasud@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6021F8584 for <dhcwg@ietfa.amsl.com>; Fri, 14 Sep 2012 00:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYnZAFzd6lLD for <dhcwg@ietfa.amsl.com>; Fri, 14 Sep 2012 00:44:48 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2D21F851E for <dhcwg@ietf.org>; Fri, 14 Sep 2012 00:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5094; q=dns/txt; s=iport; t=1347608688; x=1348818288; h=from:to:cc:subject:date:message-id:mime-version; bh=hIWWQQ/nsHBA5C75nbTMtwIVQQ7Q5RYDIgq3GCsoMhk=; b=LgzdcUBNSUyoqVrJlOJV35/VFJ+F/gNLiP4YnzgDr7pFFc+ZDOy9EffX xxQP1ak/YeYzuRREVZffpagK4GKkP8TRgi23SFSnL+21ZJPTDTrXkFLY4 zM1ZsCWUq1C6bqmD8JTuq3CdfU48RIetHSm927fVRxOkpKgR5sSgloGrP A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFADjfUlCtJV2d/2dsb2JhbAA7CoJLsE4BiF+BB4InEgFmEgEMdCcEDieHawubEaANiyWGJwOVYIEUjSSBaYJmghc
X-IronPort-AV: E=Sophos; i="4.80,421,1344211200"; d="scan'208,217"; a="118530855"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 14 Sep 2012 07:44:47 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8E7ilAO010999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Fri, 14 Sep 2012 07:44:47 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 02:44:47 -0500
From: "Anup Kumar Vasudevan (anuvasud)" <anuvasud@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Reg. Use of Link-Address Field for DHCPv6
Thread-Index: AQHNkkzP+5tdKtJ+Kke3DzPsRIaW9g==
Date: Fri, 14 Sep 2012 07:44:46 +0000
Message-ID: <CC78DE44.178D9%anuvasud@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.65.76.217]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004
x-tm-as-result: No--27.593800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC78DE44178D9anuvasudciscocom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 14 Sep 2012 10:09:48 -0700
Cc: "G Murali Krishna (gunkrish)" <gunkrish@cisco.com>
Subject: [dhcwg] Reg. Use of Link-Address Field for DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 14 Sep 2012 07:44:49 -0000

Hi

We have a query on the Link-Address field in DHCPv6 – for Relay Agents. From the RFC -


20.1.1<http://tools.ietf.org/html/rfc3315#section-20.1.1>. Relaying a Message from a Client


   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or site-scoped address with a prefix
   assigned to the link on which the client should be assigned an
   address in the link-address field.  This address will be used by the
   server to determine the link from which the client should be assigned
   an address and other configuration information.  The hop-count in the
   Relay-forward message is set to 0.

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-id option
   (see section 22.18<http://tools.ietf.org/html/rfc3315#section-22.18>) in the Relay-forward message.  The server will
   include the Interface-id option in its Relay-reply message.  The
   relay agent fills in the link-address field as described in the
   previous paragraph regardless of whether the relay agent includes an
   Interface-id option in the Relay-forward message.


Is the Link-Address field Mandatory? Should Relay-Agents always fill it? Also is it mandatory for Server to use the Link-Address field for Assigning client addresses? If the Server does not have addresses that match the Link-Address field , should it fail the Allocation requests?

We have seen in testing that some of the third party servers don't really use this field for Address Assignment – but I think the ISC implementation is dependent on this field.

Thanks

Anup

v2.23.0 | Report a Bug | By Email