Re: [dhcwg] RFC 3633 to Internet Standard

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 25 September 2013 11:37 UTC

Return-Path: <alexandru.petrescu@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 EC52821F9FF9 for <dhcwg@ietfa.amsl.com>; Wed, 25 Sep 2013 04:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.638
X-Spam-Level:
X-Spam-Status: No, score=-9.638 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 LpqInu0kPl3L for <dhcwg@ietfa.amsl.com>; Wed, 25 Sep 2013 04:37:03 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8791621F9FA3 for <dhcwg@ietf.org>; Wed, 25 Sep 2013 04:37:03 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r8PBb0IC025199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Sep 2013 13:37:00 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r8PBb0ca023299; Wed, 25 Sep 2013 13:37:00 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r8PBaxem015674; Wed, 25 Sep 2013 13:37:00 +0200
Message-ID: <5242CADB.5040000@gmail.com>
Date: Wed, 25 Sep 2013 13:36:59 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@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>
In-Reply-To: <6690AA2A-BB92-45BE-A66C-8BFFE5A441F2@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 11:37:09 -0000

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 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
>>>
>>>
>>>
>>
>>
>
>
>