Re: [dhcwg] RFC 3633 to Internet Standard

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 September 2013 07:21 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 8D39211E812E for <dhcwg@ietfa.amsl.com>; Fri, 27 Sep 2013 00:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.754
X-Spam-Level:
X-Spam-Status: No, score=-9.754 tagged_above=-999 required=5 tests=[AWL=0.495, 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 KDxsISgv8qH6 for <dhcwg@ietfa.amsl.com>; Fri, 27 Sep 2013 00:21:31 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3C11E8131 for <dhcwg@ietf.org>; Fri, 27 Sep 2013 00:21:28 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r8R7LQ3O018280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Sep 2013 09:21:26 +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 r8R7LQAb013501; Fri, 27 Sep 2013 09:21:26 +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 r8R7LPxj003103; Fri, 27 Sep 2013 09:21:26 +0200
Message-ID: <524531F6.4030502@gmail.com>
Date: Fri, 27 Sep 2013 09:21:26 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0
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> <5242CADB.5040000@gmail.com> <E3BEE054-842E-4DC6-B0E7-9018F24E3263@gmail.com>
In-Reply-To: <E3BEE054-842E-4DC6-B0E7-9018F24E3263@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: Fri, 27 Sep 2013 07:21:36 -0000

Le 25/09/2013 21:17, Ralph Droms a écrit :
>
> 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.

Not sure about that.  The PC uses RA to autoconfigure an address and 
default route, whereas the Requesting Router uses DHCP to get a prefix.


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

Right.  If the DHCPRelay is a different machine than the Access Router 
(as pictured abve) then indeed there is little chance that AR knows how 
to install a route.  Assuming it had a means to do it, later on it could 
do ICMP Redirect to the Host DHCPRelay.

But yes, there is a problem on how the AR dyncamically installs a route 
for the RequestingRouter, after the prefix allocation.  TO install that 
it needs 3 things: the trigger of the moment to do it, the value of the 
prefix, and the value of the address of the Requesting Router.

Alex

>

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