Re: [dhcwg] RFC 3633 to Internet Standard

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Tue, 01 October 2013 15:40 UTC

Return-Path: <leaf.yeh.sdo@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 248FF21E8153 for <dhcwg@ietfa.amsl.com>; Tue, 1 Oct 2013 08:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level:
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_219128=1.666]
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 zmSSzJI0qC2z for <dhcwg@ietfa.amsl.com>; Tue, 1 Oct 2013 08:40:42 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E024521F9AB4 for <dhcwg@ietf.org>; Tue, 1 Oct 2013 08:40:06 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id y13so7400293pdi.19 for <dhcwg@ietf.org>; Tue, 01 Oct 2013 08:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=/F6vqzfmryl7cz5+3oxlDVN5mqnva9eBtcTjCQWEb1g=; b=d86Y1L+MsGWQgo+DCn68r1GntmoN6X1BrPaspe3db6Tn8qnhOJGmI5FznrtmNyZJo0 Hz9MivNc2tiomhZn2aChXKDqu5fKHqcYEJBcAgkqKny2rSfNUdUnUeyOAOXY6obOnedD L1jHuOpCxlC2jE76oOSAuWv+4E95/e7qyLiVGNbWuSKMtmSSmg5bkyjKpKxUtddSu2fz I9isSGZVQ2U6t9cCd8q0vi6OkKwn7oCtBRULUQ7f7ZaHb+EGd33drGdpGaOg6i6R4pLK rZ0uQWh9pVlvD2z6cSurhZJBIMMeaIIiTmwGTCYPsVuYY2tifYxgdE0/DzxLdhHR9Ecz nQsA==
X-Received: by 10.66.190.198 with SMTP id gs6mr34011130pac.49.1380642005346; Tue, 01 Oct 2013 08:40:05 -0700 (PDT)
Received: from PC ([219.133.129.162]) by mx.google.com with ESMTPSA id nj9sm7507387pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Oct 2013 08:40:04 -0700 (PDT)
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: 'Ralph Droms' <rdroms.ietf@gmail.com>, 'Alexandru Petrescu' <alexandru.petrescu@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>
Date: Tue, 01 Oct 2013 23:39:57 +0800
Message-ID: <524aecd4.69d4440a.25d9.ffffba0c@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac66I+8y/eP7hllhTIam59Q8Pw+/WAASJ+nw
Content-Language: zh-cn
Cc: 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: Tue, 01 Oct 2013 15:40:44 -0000

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

I guess Ole's answer in the thread of 'Re: [dhcwg] Advancing RFC 3315 and
RFC 3633 to Internet Standard' was '...everyone does this with snooping
today...'


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Ralph Droms
Sent: Thursday, September 26, 2013 3:18 AM
To: Alexandru Petrescu
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] RFC 3633 to Internet Standard


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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg