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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 17 September 2012 00:58 UTC

Return-Path: <volz@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 2D19021F8499 for <dhcwg@ietfa.amsl.com>; Sun, 16 Sep 2012 17:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level:
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 3tBfFSYYEfFb for <dhcwg@ietfa.amsl.com>; Sun, 16 Sep 2012 17:58:27 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8321F847F for <dhcwg@ietf.org>; Sun, 16 Sep 2012 17:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16956; q=dns/txt; s=iport; t=1347843507; x=1349053107; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=coHHYX+/Sp181T8QlclX0m0L/Hx3uJtLCf1GcERndYk=; b=amLjIv8KNpRPew/PggCMjtx5R22dF1VegQpfMsh4ugZiTQZB8XoCXxXz pIVArquJ7ovG0PbhNaFwe4yEl902F+58Ist+EQWtQwAcMxmDceTlxgNYF dekwmte4cwVjD34JQUNtlbMGbumSOkcZ4BwxwGKE5dGazBnz8Ig/c67d0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjUFAJF0VlCtJXG8/2dsb2JhbAA7CoJLsGQBiGOBB4IgAQEBBBIBGkwQAgEIEQQBAQsdBzIUCQgCBAENBQgah14LmlOfGoshEIV4YAOSMYRFjSSBaYJmghc
X-IronPort-AV: E=Sophos; i="4.80,432,1344211200"; d="scan'208,217"; a="121933186"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 17 Sep 2012 00:58:26 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8H0wQmt019503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dhcwg@ietf.org>; Mon, 17 Sep 2012 00:58:26 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sun, 16 Sep 2012 19:58:25 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Anup Kumar Vasudevan (anuvasud)" <anuvasud@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Reg. Use of Link-Address Field for DHCPv6
Thread-Index: AQHNkkzP+5tdKtJ+Kke3DzPsRIaW9peNuWJA
Date: Mon, 17 Sep 2012 00:58:25 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4FFC62@xmb-rcd-x04.cisco.com>
References: <CC78DE44.178D9%anuvasud@cisco.com>
In-Reply-To: <CC78DE44.178D9%anuvasud@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.245.87]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002
x-tm-as-result: No--32.303600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4FFC62xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "G Murali Krishna (gunkrish)" <gunkrish@cisco.com>
Subject: Re: [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: Mon, 17 Sep 2012 00:58:29 -0000

Ideally all relay agents would fill in this value. If they don't, it should be set to all 0's (128 bits of 0).

If no address is specified in the link-address field, a server would try an outer Relay-Forw to see if it has a link-address (and so on). If no relay specified the link-address, the server only has either the source address of the packet or the interface on which it was received in order to determine where the client is located. Neither of these is probably correct.

The bottom line is that a relay agent should fill in the link-address field with information about where the client is located that the server can use to assign appropriate addresses or delegate appropriate prefixes.


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Anup Kumar Vasudevan (anuvasud)
Sent: Friday, September 14, 2012 3:45 AM
To: dhcwg@ietf.org
Cc: G Murali Krishna (gunkrish)
Subject: [dhcwg] Reg. Use of Link-Address Field for DHCPv6

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