Re: [dhcwg] RFC 3633 to Internet Standard

Ralph Droms <rdroms.ietf@gmail.com> Wed, 25 September 2013 19:17 UTC

Return-Path: <rdroms.ietf@gmail.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 F3A9A21F9C33 for <dhcwg@ietfa.amsl.com>; Wed, 25 Sep 2013 12:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oQyjPjJ4tht for <dhcwg@ietfa.amsl.com>; Wed, 25 Sep 2013 12:17:47 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7261F21F9C40 for <dhcwg@ietf.org>; Wed, 25 Sep 2013 12:17:46 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id n4so79350qcx.27 for <dhcwg@ietf.org>; Wed, 25 Sep 2013 12:17:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZUTzHu3N5tOP1To3a3GQAm39erB7NUPRwb0IvzioQbo=; b=CcfVHomjkT4ej1HFEbBKnNwr3xB0IiOC9/G8KibtSfLD5bCZyRkSKrQpYbY6LULwpw BLMRzRbJ5aXJgPt5UyqefjelhebnU6znQjEbYjZXdOwUYnutMy1+VG+KkuJ9iycXCm9b 1LtK7akj8P4A8SZT6/XIijjaHZH6v0vuSsqJ25sLE+d0Jmo856yisqAVH//V/bdejjn6 usdGek3QjI56eJIKv+474afeCRqGaMLDHYPE5sL8s70/WXizH2zrRQsvZCMiG1H0n1f0 LoF6+nl+bBBV2M3QyE+dOUxFre26DOR4UoKuhHD8nmVfVXKLhrJdqpCziJPFkeTVZpV3 4qig==
X-Received: by 10.229.174.3 with SMTP id r3mr47258555qcz.10.1380136664865; Wed, 25 Sep 2013 12:17:44 -0700 (PDT)
Received: from che-vpn-cluster-2-297.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id h6sm64890742qej.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 12:17:44 -0700 (PDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <5242CADB.5040000@gmail.com>
Date: Wed, 25 Sep 2013 20:17:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3BEE054-842E-4DC6-B0E7-9018F24E3263@gmail.com>
References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> <5212694A.6000807@gmail.com> <CAOv0Pi87akb24PaYJKPzK3+cfCr1DHDu-h2sF3HwTxBvzZC9+w@mail.gmail.com> <C2A9B74C-A52C-4605-824E-40E3E9C190E0@gmail.com> <52305986.2010503@gmail.com>, <FB56FE0A-9088-4040-BCE7-C69399D64171@employees.org> <ECD231FD-8D3F-4067-8BDE-AE567D96F6A7@cisco.com> <52306010.4090001@gmail.com> <5E91E9B8-6E22-46DD-A687-B4983BD0B508@gmail.com> <523f2fa3.c9ed440a.55a9.ffffc38e@mx.google.com> <52402AF3.8010407@gmail.com> <5240486E.20501@gmail.com> <52405701.9070506@gmail.com> <2CC893E4-7C48-4345-A40E-E2B3822C14ED@gmail.com> <5241951B.2070606@gmail.com> <6690AA2A-BB92-45BE-A66C-8BFFE5A441F2@gmail.com> <5242CADB.5040000@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] RFC 3633 to Internet Standard
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: Wed, 25 Sep 2013 19:17:48 -0000

On Sep 25, 2013, at 12:36 PM 9/25/13, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

> Le 24/09/2013 22:43, Ralph Droms a écrit :
>> 
>> On Sep 24, 2013, at 2:35 PM 9/24/13, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
>> 
>>> Le 24/09/2013 10:32, Ralph Droms a écrit :
>>>> 
>>>> On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu
>>>> <alexandru.petrescu@gmail.com> wrote:
>>>> 
>>>>> Le 23/09/2013 15:55, Tomek Mrugalski a écrit :
>>>>>> On 23.09.2013 13:50, Alexandru Petrescu wrote:
>>>>>>> Le 22/09/2013 19:57, Leaf Yeh a écrit :
>>>>>>>> Ralph > The piece of network equipment that implements the
>>>>>>>> relay agent routes, and that network equipment *might* also
>>>>>>>> need a route.
>>>>>>>> 
>>>>>>>> On the PE router implementing relay for DHCPv6-PD, it always
>>>>>>>> needs add the associated route for the CE's network of
>>>>>>>> delegated prefix. I can't see *might* here.
>>>>>>> 
>>>>>>> I agree with the doubt.  I don't see a might, but rather a
>>>>>>> must. Otherwise it doesn't work.
>>>>>>> 
>>>>>>> But maybe I dont understand the word 'might' as a native
>>>>>>> speaker could hear it.
>>>>>> Relay agent is functionality that can be provided by a piece of
>>>>>> software. You can run it on any box that is connected to more
>>>>>> than one network. Although typically such a box serves as a
>>>>>> router, it doesn't have to.
>>>>> 
>>>>> You mean a Relay agent which runs on a pure Host (single real
>>>>> interface, no additional virtual/real interfaces)?
>>>>> 
>>>>> Even in that case it (or the Router on the same link which is
>>>>> connected to the Internet) will need to install a route towards
>>>>> the Requesting Router's interface for the delegated prefix.
>>>> 
>>>> And there's the exact point of the discussion - if the relay agent
>>>> is not implemented on the router that needs the route, passing the
>>>> route in the DHCPv6 message exchange through the relay agent won't
>>>> get the route to the appropriate router.
>>>> 
>>>>> 
>>>>> In all cases, the Relay and other routers on that link MUST
>>>>> install a route.
>>>> 
>>>> And how does that route get to the other routers?
>>> 
>>> They are all on the same link, and one mechanism used to install routes
>>> dynamically is during ICMP Redirect.
>> 
>> According to RFC 4861, sec. 8.2, routers ignore ICMPv6 Redirect messages:
>> 
>>    A router MUST NOT update its routing tables upon receipt of a
>>    Redirect.
>> 
>> I don't recall if that text is updated by subsequent RFCs.
> 
> I don't know either whether subsequent RFCs update it, or whether linux has knobs allowing that - one should check.
> 
> And, what I meant is not a necessarily a Router but maybe a Host DHCPRelay:
>                        ________ ----------
>                       |        |DHCPServer|
>                      ...        ----------
>                       |
>    ----------     ---------
>   | Host     |   | Access  |
>   | DHCPRelay|   | Router  |
>    ----------     ---------
>        |              |
>    ----+--------------+
>        |
>    ----------     ----
>   |Requesting|   | PC |
>   | Router   |   |    |
>    ----------     ----
>        |            |
>    ----+------------+--
> 
> After the PD phase, and after the assumed route insertion in Access Router, the Host DHCPRelay would get an ICMPRedirect from the Access Router whenever wanting to talk to PC.  The route it installs is for the Delegated Prefix.

The "Host DHCPRelay" has to be on the same link with the PC.

How does the Access Router know the route through the RR to the PC?  I thought that was the information that needs to be installed on the Access Router.

- Ralph

> 
> (the topology above has some advantages in terms of rapid deployment of DHCPv6 in a hostpot network).
> 
> Alex
> 
>> 
>>> 
>>>>> Whether they do it at allocation time, at ICMP Redirect time, or
>>>>> at manual config time - is another matter.
>>>> 
>>>> I'm not saying the route installation can't be accomplished through
>>>> DHCPv6.  I think you'll need to address the specific issues I raised
>>>> in previous e-mail to publish a specification for passing routing
>>>> information to the appropriate router through a DHCPv6 message
>>>> exchange with a host.
>>> 
>>> Ok, my point is whether or not we could formulate a problem statement
>>> for this: there is a need for a route in the concerned routers, after
>>> the PD operation.  Without that route the communication can't be
>>> established between Hosts configured with an address prefixed by the
>>> delegated prefix.
>> 
>> I agree that there is a need for the route to exist and an appropriate problem statement could be formulated.
>> 
>> - Ralph
>> 
>>> 
>>> Alex
>>> 
>>>> 
>>>> - Ralph
>>>> 
>>>>> 
>>>>> Without that route the whole schmillblick doesn't work.
>>>>> 
>>>>> Alex
>>>>> 
>>>>> 
>>>>> _______________________________________________ dhcwg mailing list
>>>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>