Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

"Leaf Yeh" <> Sun, 22 September 2013 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFD2711E8114 for <>; Sun, 22 Sep 2013 10:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Pn+n6kNdwB3 for <>; Sun, 22 Sep 2013 10:58:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22a]) by (Postfix) with ESMTP id 83EC011E8111 for <>; Sun, 22 Sep 2013 10:58:00 -0700 (PDT)
Received: by with SMTP id un15so2337450pbc.29 for <>; Sun, 22 Sep 2013 10:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=04uuR5oiiik2kNdSNhf8BJVl+2sfkgaPLvG1BB588ts=; b=lskdgSYqX8y6n28DgR4C59CJ34/CyI4AMIha/WSAXzBih8GG2B7e3qWFr10uXUUW2j qlQHRbRX4qSbXR8iyMVDrt9AsXLphR6AcY2W+PprV5qUKsm1xhoahiDK1hcP/YIwF/Im N4ksyJCj+eE/og0mA/93M/KH9GABB59JzPTmnwOKkFlAGg6xAKfXiAKIsca7SAGjibyI IQqjOvHOwNdz0Fk21s+A/nLYjmxGKQS3hMc+vcf67ZTtJkw2h5QwIkjK21JyC1Aj/5qB rhPG82fWUhWE/y0En5oQadrwLWirP/Q8EvfLJQBNmpfYAcGU2NixUg56iJ/ogdNXbYpQ Runw==
X-Received: by with SMTP id yk7mr3499242pab.136.1379872680247; Sun, 22 Sep 2013 10:58:00 -0700 (PDT)
Received: from PC ([]) by with ESMTPSA id ve9sm29079060pbc.19.1969. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 22 Sep 2013 10:57:59 -0700 (PDT)
From: "Leaf Yeh" <>
To: "'Ole Troan'" <>, "'Alexandru Petrescu'" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 23 Sep 2013 01:57:48 +0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6u5xTN8NszrHg1T+GfO8aTiHxZCgI1RcRg
Content-Language: zh-cn
Cc:, 'Ralph Droms' <>, "'Bernie Volz \(volz\)'" <>
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Sep 2013 17:58:13 -0000

Ole - the closest we got to exploring the options was in 

I can't find the description on the behavior of DHCPv6 *server* in this

   A prefix delegation deployment consists of Requesting Routers (RR),
   Delegating Routers (DR) and possibly a backend provisioning system
   (see Figure 1).

Who is assumed to be the DHCPv6 *server* in this document ?

Best Regards,

-----Original Message-----
From: [] On Behalf Of
Ole Troan
Sent: Wednesday, September 11, 2013 8:04 PM
To: Alexandru Petrescu
Cc:; Ralph Droms; Bernie Volz (volz)
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard


>>> In RFC 3315 DHCPv6-PD there is a questionable use of the term 
>>> 'provider edge router.' in a section describing the behaviour of the 
>>> Relay agent:
>>> 14.  Relay agent behavior
>>> A relay agent forwards messages containing Prefix Delegation options 
>>> in the same way as described in section 20, "Relay Agent Behavior" 
>>> of RFC 3315.
>>> If a delegating router communicates with a requesting router through 
>>> a relay agent, the delegating router may need a protocol or other 
>>> out-of-band communication to add routing information for delegated 
>>> prefixes into the provider edge router.
>>> I wonder whether the Authors actually meant 'Relay Agent' by that 
>>> 'provider edge router'. Because otherwise the term doesn't appear 
>>> elsewhere in the document.
>> (Assuming you meant RFC3633) Yes, s/provider edge router/relay agent/
> Yes, I meant RFC3633, and yes s/provider edge router/relay agent.
> That would make for an errata that one could suggest in the errata site?

I'm not sure I see what difference it would make?

>>> Also, did the authors of RFC3315 meant that a new protocol is needed 
>>> between Server and Relay Agent?  Or did they mean that inserting a 
>>> routing table should happen by that 'out-of-band' means (and not 
>>> 'out-of-band communication')?
>> Not speaking for Ole, I meant that some other means, which might be a 
>> protocol, manual configuration, etc., is needed to add routing 
>> information into the relay agent.
> In that sense I agree with it.  It is thus a problem that is already
explicit in this RFC.

everyone does this with snooping today, but that's not covered by any RFC.
the closest we got to exploring the options was in