[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)
A concern I raised on the list a while back centers around
the behavior of the CPE router acting as a host on its WAN
interface per section 4.1:
"When the router is attached to the WAN interface link it must act as
an IPv6 host for the purposes of stateless or stateful interface
address assignment ([RFC4862]/[RFC3315])."
and per WPD-3:
"WPD-3: Absent of other routing information the IPv6 CE router MUST
use Router Discovery as specified in [RFC4861] to discover a
default router and install a default route in its routing
table with the discovered router's address as the next-hop."
To my understanding, this behavior would involve the CPE
router sending Router Solicitation (RS) messages on its
WAN interface in order to receive Router Advertisement (RA)
messages. According to Section 6.2.6 of RFC4861, however:
"Whether or not a Source Link-Layer
Address option is provided, if a Neighbor Cache entry for the
(RS)'s sender exists (or is created) the entry's IsRouter flag
MUST be set to FALSE."
RFC4861 goes to some level of detail to specify the setting
of the IsRouter flag under various circumstances (including
the RS case), but it only says what actions should be taken
based on the flag as result of receiving Neighbor Advertisement
messages. Other actions based on the IsRouter flag setting do
not seem to be specified.
In the linux kernel, it appears that the kernel will in some
circumstances garbage-collect FIB entries that have a nexthop
with the IsRouter flag set to FALSE. It is not clear what other
router implementations would do based on the IsRouter setting,
but it seems odd that the IsRouter flag in neighbor cache
entries corresponding to CPE routers would be set to FALSE
which in the linux case at least may lead to interoperability
As a result, it might be worth reconsidering whether it is
appropriate for the CPE router to send an RS which might
confuse other routers into thinking it is a host.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Fred Baker
> Sent: Monday, January 04, 2010 7:45 AM
> To: email@example.com
> Cc: firstname.lastname@example.org; email@example.com
> Subject: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC
> This is to initiate a two week working group last call of draft-ietf-
> v6ops-ipv6-cpe-router-03.txt. Please read it now. If you find nits
> (spelling errors, minor suggested wording changes, etc), comment to
> the authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed,
> please post your comments to the list.
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.
> On Dec 18, 2009, at 2:45 AM, firstname.lastname@example.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> This draft is a work item of the IPv6 Operations Working Group of the
> Title : Basic Requirements for IPv6 Customer Edge Routers
> Author(s) : H. Singh, et al.
> Filename : draft-ietf-v6ops-ipv6-cpe-router-03.txt
> Pages : 14
> Date : 2009-12-18
> This document specifies requirements for an IPv6 Customer Edge (CE)
> router. Specifically, the current version of this document focuses
> on the provisioning of an IPv6 CE router and the provisioning of IPv6
> hosts attached to it.
> Status of this Memo
> This Internet-Draft is submitted to IETF in full conformance with the
> provisions of BCP 78 and BCP 79.
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
> The list of current Internet-Drafts can be accessed at
> The list of Internet-Draft Shadow Directories can be accessed at
> This Internet-Draft will expire on June 21, 2010.
> Copyright Notice
> Copyright (c) 2009 IETF Trust and the persons identified as the
> document authors. All rights reserved.
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document. Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document. Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
> A URL for this Internet-Draft is:
> Internet-Drafts are also available by anonymous FTP at:
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> I-D-Announce mailing list
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt