Subject: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC

From: Fred Baker <[email-masked]>
Date: Mon, 4 Jan 2010 07:45:12 -0800

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, [email-masked] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.
This draft is a work item of the IPv6 Operations Working Group of the  
IETF.

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

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
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

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:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<mime-attachment>_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

http://www.ipinc.net/IPv4.GIF

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jan 2010 17:00:33 -0800

Fred,

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

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.

Fred
[email-masked]  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Monday, January 04, 2010 7:45 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Jan 2010 08:25:49 -0600

-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
>Sent: Monday, January 04, 2010 8:01 PM
>To: Fred Baker (fred); [email-masked]
>Subject: CPE router acting as host on its WAN interface (RE:
draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

>interface per section 4.1:

6man hasn't even agreed with you as to what is the problem with your
IsRouter flag discussion.

>not seem to be specified.

Not quite.  By default the IsRouter flag is set of FALSE.  Also, see
Appendix D of RFC 4861.

issues.

What specific interoperability issues? What specific circumstances?
Further, since the FIB includes the Destination Cache, note that NUD
purges entries in the Destination Cache. Garbage collection can remove
an entry from the Default Router List - every entry in the Default
Router List is a router.  NUD can also purge entries in the Neighbor
cache.  If the CE Router sends an RS from its WAN interface, the router
receiving such and RS sets the IsRouter flag for the CE Router entry to
FALSE.  So what?  When the CE Router requests a delegated prefix, the
delegating router will know the CE Router is requesting router. 

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jan 2010 08:59:40 -0800

Hemant,

> From: Hemant Singh (shemant) [mailto:[email-masked]]
> Sent: Tuesday, January 05, 2010 6:26 AM
> To: Templin, Fred L; Fred Baker (fred); [email-masked]
> Subject: RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
> 
> 

The IsRouter discussion was on this list (v6ops); not
the 6man list. Maybe you were talking about a different
discussion on the 6man list?

> Not quite.  By default the IsRouter flag is set of FALSE.  Also, see

Yes, I include Appendix D in what I am meaning when I say
that "RFC4861 goes to some level of detail to specify the
setting of the IsRouter flag". But, it still doesn't say
what actions (if any) a host or router should take based
on the IsRouter setting.

The final sentence of Appendix D also says:

  "In these cases, a subsequent Neighbor
   Advertisement or Router Advertisement message will set
   the correct IsRouter value."

but if the CPE will not send any RA messages over its
WAN interface then the NA is the only other option for
setting the correct IsRouter value.

> What specific interoperability issues? What specific circumstances?

If a provider router garbage-collects a FIB entry because
it sees that IsRouter in the nexthop nbr cache entry is
FALSE, the FIB entry is gone and there is no route to the
CE router's prefixes. That is what I am meaning to say
regarding interoperability issues and circumstances.

> delegating router will know the CE Router is requesting router.

First, the delegating router need not be co-resident on
the provider router that sends RA to the CE router; it
could be behind a chain of relays instead. Second, just
because the delegating router (and I guess also any
relays in the chain) come to know that the CE router is
a requesting router does not necessarily mean that the
provider router will know enough to reach into its kernel
and set the IsRouter flag in the nbr cache entry to TRUE.
Or, maybe that behavior is specified somewhere that I
didn't see?

I know about the RAAN option draft, and I can see that the
intent there is to have the relays in the chain come to know
about delegated prefixes so that they can inject them into
the routing system. But, that document does not seem to discuss
interactions with the IPv6 ND protocol, including the setting
of the IsRouter flag.

It also seems that DHCP prefix delegation is being used as a
routing protocol. The alternative is to use IPv6 ND RAs as a
routing protocol.

Fred

---

From: james woodyatt <[email-masked]>
Date: Tue, 5 Jan 2010 10:53:35 -0800

> setting the correct IsRouter value.

Perhaps, now would be a good time for me to reiterate my complaint that we don't have a good zero-configuration, stateless routing protocol built into ICMP6.  RA and RS are conceptually tied to the roles of default router and host, specifically, and they quite unsuitable for use in a model where a host on one prefix is also a router for another, delegated, prefix.

I'm inclined to think we should take the Route Information Option from RFC 4191 and define a way to add it to the Neighbor Advertisement message.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 11:00:49 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker

Document seems useful.

I have an issue with L-9, "The IPv6 CE router MUST support providing
DNS information in the DHCP DNS_SERVERS option [RFC3646]".  This
prevents a network from operating both IPv6-only hosts (which want to
access the IPv4 Internet using DNS64+NAT64, and thus need a DNS64 as
their recursive resolver) and dual-stack hosts (which need a 'normal'
DNS as their recursive resolver) simultaneously.  I just sent email to
the authors and chairs with additional detail, and am shortly going to
publish an Internet Draft discussing this issue in more detail.

Section 3.1 should additionally mention that an end-network
IPv4 CPE that incorporates a NAT also incorporates a DHCPv4 
server.  The inclusion of a DHCP server in the CPE is implied, 
but should be explicitly stated.  The DHCP server in the CPE 
allows the in-home network to be self-sufficient (for IP 
addressing, if not naming).

This is relevant to IPv6 because, I have been told, ULAs
provide a similar "LAN only" address.  This should be
mentioned or a pointer to how hosts inside the home should
use ULAs mentioned.  We do not want streaming between an
in-home NAS and an in-home television to rely on the
WAN link's availability.  This is mentioned (insufficiently)
in Section 4.2 and some of the L-* requirements.

The definition of Service Provider is "a company that ...",
which precludes non-companies such as, for example, a University 
offering service to students in University housing.  Is that intentional?

Many of the enumerated requirements contain multiple "MUSTs" or "SHOULDs".
This makes things complicated, because a vendor (or a customer) cannot say,
for example, "we comply with all of RFCxyz, except L-5" because L-5 contains
three MUSTs and one SHOULD.  Taking L-5 as an example, I suggest changing
from:

OLD:
   L-5:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix (and ULA prefix if configured to provide ULA
          addressing) for each of its LAN interfaces.  The IPV6 CE
          router MUST make the interface an advertising interface
          according to [RFC4861].  In router advertisements messages,
          the Prefix Information Option's A/L-bits MUST be set to 1 by
          default; the A/L bits setting SHOULD be user configurable.
NEW:
   L-5:   a. The IPv6 CE router MUST assign a separate /64 from its 
             delegated prefix (and ULA prefix if configured to 
             provide ULA addressing) for each of its LAN interfaces.
          b. The IPV6 CE router MUST make the interface an advertising 
             interface according to [RFC4861].  
          c. In router advertisements messages, the Prefix Information 
             Option's A/L-bits MUST be set to 1 by default; 
          d. the A/L bits setting SHOULD be user configurable.

This would allow a vendor (or a customer) to say "we comply with all of
RFCxyz, except L-5c and L5-d".

Nits are being sent directly to the authors.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Jan 2010 08:48:10 +1300

On 2010-01-06 08:00, Dan Wing wrote:
...
> addressing, if not naming).

Sure, for IPv4, you need DHCP, but...

> in Section 4.2 and some of the L-* requirements.

I don't understand what you're getting at here. Whether the
LAN uses a ULA prefix is orthogonal to whether it uses
DHCPv6. It can be set up by RAs and SLAAC (or even manually,
but that's unlikely).

I think the L-* requirements for ULAs are necessary and sufficient.
Despite the problems with RFC3484, I think the provision of a ULA
prefix by the CPE will bring about local streaming automatically.
That was certainly the intention behind ULAs.

     Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 12:16:03 -0800

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, January 05, 2010 11:48 AM
> To: Dan Wing
> Cc: 'Fred Baker'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: ULAs [Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> 
> DHCPv6.

Agreed; but I didn't say DHCPv6 was needed to assign ULAs (you did).

> It can be set up by RAs and SLAAC (or even manually,
> but that's unlikely).
> 

I agree the L-* requirements for ULAs are sufficient.

I am asking for more explanatory text about the value and purpose
of ULAs (or a pointer to such explanatory text), in Section 3.2
"IPv6 end-user network architecture", because Section 3.2's only
mention of ULA is that the CE Router is a "ULA boundary".

We're in WGLC, so my suggested text for Section 3.2 is along
the lines of something like this:

   Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] are used
   by hosts communicating within the End-user Network; this is
   functionally similar to RFC1918 addresses used within an
   IPv4 End-user Network.

and place that sentence immediately prior to the sentence in Section 
3.2 starting with "The IPv6 CE router defaults to acting as 
the demarcation point ...".

> That was certainly the intention behind ULAs.

I'm asking for text to provide motivation for the existing L-1 
requirement (which reads "The IPv6 CE router MUST support ULA 
addressing [RFC4193]").

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Jan 2010 10:15:10 +1300

Dan,

I'm fine with your suggested text.

Regards
   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Jan 2010 15:41:45 -0600

Dan,

Sorry, in my reply, I missed seeing that you had already suggested text
as motivation for use of ULA.  Your text looks OK to me.

Thanks much.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Jan 2010 15:37:52 -0600

>From: Dan Wing (dwing) 
>Sent: Tuesday, January 05, 2010 3:16 PM
>To: 'Brian E Carpenter'
>Cc: Fred Baker (fred); [email-masked]; [email-masked];
>Subject: RE: ULAs [Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]

>requirement (which reads "The IPv6 CE router MUST support ULA 

About two years back Brian Carpenter gave the dentist's office as one
motivation for use of ULA in the home with the CE Rtr. The dentist's
office network is setup once and that's how it runs for a long time.  If
the Internet WAN link of the dentist's office CE Rtr goes down, the
dentist can still print from his office PC to his printer which are both
using ULA.  The other motivation that is also in emails of v6ops
archives is that what does one do for configuration of the CE Rtr right
out of shrink-wrap?  The user bought the device from retail and powered
it up in the home before attaching the CE Router to any WAN.  Without a
GUA (Globally Unique Address), how does one configure the CE Rtr if
using link-local is spotty at best to access a device with a link-local
URL.  You see, the link-local can be common to all LAN ports of the CE
Rtr and that is why it's not a good address to use to configure the CE
Rtr in a web browser.  So that leaves only the GUA (auto-configured on
the CE Rtr on power up) to configure the device with using a web
browser.  Auto-configuration of the CE Rtr is part of the Phase II
document, so any more details in the current CE Rtr doc (Phase I) will
be skipped.

If none objects that motivation for use of ULA needs to be included as
text in the CE Rtr doc, what we can do is work on a formal version of
what I have summarized above.

Further, in an earlier version of the CE Rtr we also said the ULA and
the GUA coexist on a LAN network interface.  Since the addresses
coexist, here is what our earlier version said about RFC 3484.  

"... every LAN interface has a link-local unicast address, a ULA, and a
GUA.  Therefore, the interface has to apply source address selection to
determine which address to use as a source for outgoing packets.  Since
the GUA and ULA have a larger scope than the link-local address (rule #2
of [RFC3484]), the GUA or ULA will be used as a source address of
outgoing packets that are not subject to rule #1.  For source address
selection between a GUA and ULA, rule #8 of [RFC3484] will be used."

In the -03 version we have removed such text.

Thanks,

Hemant

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 14:09:34 -0800

> From: Mark Smith 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 05, 2010 2:06 PM
> To: Hemant Singh (shemant)
> Cc: Dan Wing (dwing); Brian E Carpenter; Fred Baker (fred); 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: ULAs [Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> 
> On Tue, 5 Jan 2010 15:37:52 -0600
> "Hemant Singh (shemant)" <[email-masked]> wrote:
> 
> > 
> > >Subject: RE: ULAs [Re: 
> draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> > 
> Somewhat related, is there room in this ID for adding 
> Zerconf/multicast
> DNS etc. for the convenience of browsing or device name based 
> discovery
> to be able to configure the device via a web/ software application
> interface? ULAs are great for this purpose, but end-users should never
> have to work out what they are type them into anywhere, and I think
> there should be a standard mechanism to discover CPE configuration
> interfaces. Or is it out of scope?

The hosts (and users on the hosts) might care, but the CE router
doesn't need to be involved in mDNS, does it?  Feels out of scope
to me, for whatever that's worth.

-d

> Regards,
> Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jan 2010 08:36:17 +1030

> document, so any more details in the current CE Rtr doc (Phase I) will

Somewhat related, is there room in this ID for adding Zerconf/multicast
DNS etc. for the convenience of browsing or device name based discovery
to be able to configure the device via a web/ software application
interface? ULAs are great for this purpose, but end-users should never
have to work out what they are type them into anywhere, and I think
there should be a standard mechanism to discover CPE configuration
interfaces. Or is it out of scope?

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Jan 2010 16:11:46 -0600

>From: Templin, Fred L [mailto:[email-masked]] 
>Sent: Tuesday, January 05, 2010 12:00 PM

>discussion on the 6man list?

No.  I am talking about "Stub Router Advertisements in IPv6
NeighborDiscovery" that was being discussed in the 6man mailer between
you, Bob Hinden and Thomas Narten.  One example of your IsRouter
discussion is an email with following date, time, etc. to the 6man list
of [email-masked].

"Sent: Tuesday, November 24, 2009 11:37 AM"

>setting the correct IsRouter value.

Yes, the CE Rtr is not expected to send any RA over its WAN interface
upstream to the SP.  So what's the concern if the SP router upstream of
the CE Rtr has an incorrect IsRouter value temporarily?  When the CE Rtr
is a requesting router for delegated prefix, the SP router knows the CE
Rtr is a router.  Note the CE Rtr is both a host and a router.

>Or, maybe that behavior is specified somewhere that I

The FIB does NOT include the Neighbor cache, so why are you discussing
"nbr cache entry"? Further, since DHCPv6 (used for requesting a
delegated prefix) travels over a link-local address, the CE Rtr will see
only the SP router that is in the CE Rtr link-local domain.  Therefore
any discussion of relay and chains is moot.  Sorry, I still don't see a
clear problem definition from you.

Hemant

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jan 2010 09:10:13 +1030

Hi Dan,

On Tue, 5 Jan 2010 14:09:34 -0800

> to me, for whatever that's worth.

With residential IPv4 CPE, it's easy enough for customers to type in
e.g. 192.168.1.1 off of a supplied piece of paper in the box to get to
the CPEs configuration interface to type in authentication details
etc., and easy enough for helpdesk staff to get customers to type in
over the phone for service troubleshooting (in the context of customer
owned and chosen CPE, which is the case here in .au). Different CPE do
use different RFC1918 addresses, however the set of them is fairly
small, and they're usually all within the 192.168/16 range. Sometimes
it's printed on the label on the bottom of the device.

Having an end-user accurately type in an equivalent IPv6 address, even
a common one, is going to be hard, and with ULAs being customer
specific, a lot of time would be spent just working with the customer
to determine what the ULA of their CPE is, to then access the web
interface.

Some vendors get around these issues by supplying setup software
that performs the device discovery. While that's a user friendly
solution, for a helpdesk, the ubiquity of a web browser and web
interface on the CPE is a useful and reliable minimum.

I suppose these issues could be out of scope for this draft, if it is
focused only on the IPv6 functions the CPE has to support, rather than
issues like configuration interfaces etc. mDNS possibly falls across
the boundary between in and out of scope - useful if it's a fundamental
feature of all IPv6 CPE (in scope), but only really there to facilitate
CPE configuration (out of scope).

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jan 2010 14:46:16 -0800

Hemant,

> Sent: Tuesday, January 05, 2010 2:12 PM

Does the SP router know enough to update the neighbor
cache entry for a CE router and and change IsRouter from
FALSE to TRUE based only on the act of delegating a prefix?
Where is that behavior specified?

> "nbr cache entry"?

No; the FIB does not include the neighbor cache and that is
not what I said. The neighbor cache is a per-interface data
structure, and FIB entries maintain a "next_hop" that points
to a neighbor cache entry. If a FIB entry garbage-collection
algorithm examines the IsRouter flag in the neighbor cache
entry to which the FIB entry points, and the flag is FALSE,
the FIB entry may be incorrectly purged.

> Further, since DHCPv6 (used for requesting a

I don't want to address the DHCP relay point because it
is a distraction from the core problem definition, which
I provided above.

Fred

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 05 Jan 2010 14:54:16 -0800

I agree that using mDNS to advertise the location of the web service
that could be used to configure the CPE router is a good thing to do,
and I have advocated such directly to more than one manufacturer.

That said, it is out of scope for this document unless we want to continue
down the path of writing a CPE PRD.

tom

At 02:40 PM 1/5/2010, Mark Smith wrote:

> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 15:06:03 -0800

> Sent: Tuesday, January 05, 2010 2:40 PM
> To: Dan Wing
> Cc: 'Hemant Singh (shemant)'; 'Brian E Carpenter'; 'Fred 
> Baker (fred)'; [email-masked]; [email-masked]; 
> > > Subject: Re: ULAs [Re: 
> > > > [email-masked]; 
> a common one, is going to be hard,

Agreed.  Made worse because the HTTP syntax needs "[]" around 
an IPv6 address literal.

> and with ULAs being customer

Some IPv4 CPE solve that problem by hijacking DNS queries (and 
sending, as the response, the NAT's internal IP address) or by 
intercepting outbound TCP/80 and re-routing it to the NAT's HTTP
server.  Once the IPv4 CPE is happily configured, it steps out
of the way and quits interfering.

I can see everyone shaking their heads, because IETF would not
sanction doing such nasty things.  (However, this is why 
configuring IP is considered 'hard', but I digress.)

mDNS would be better than the existing techniques.

> CPE configuration (out of scope).

We had a thread, a year ago, on an IETF list (I thought it was v6ops?) about
how we might do something like http://ce-router, but I don't recall where it
went.

I agree with you that a standard way for the CE router to be found would be
beneficial, so the vendor could create a one-page instruction manual that
shows its simple-to-type HTTP URI.  

Could we get consensus that mDNS is the way to accomplish this goal?  For
example, when you say mDNS do you mean RFC4795 (which was previously called
draft-ietf-dnsext-mdns), draft-mdns-rfc-informational-00 (published November
2009), or draft-cheshire-dnsext-multicastdns.  I believe you mean
draft-cheshire-dnsext-multicastdns.

-d

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Jan 2010 18:16:34 -0600

Mark and Dan,

Please see this draft below which is a placeholder for any work moved
out of CE Rtr Phase I work.

http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis-01

Please see section 6.4.  One reason we moved zeroconf out of Phase I of
the CE Rtr document is because folks may not agree if zeroconf even
belongs in an IETF CE Rtr document.  Another reason was to decide what
IETF RFC we could use to reference mDNS - that is what you guys are
currently discussing.

Thanks,

Hemant

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 16:53:00 -0800

> Sent: Tuesday, January 05, 2010 4:17 PM
> To: Dan Wing (dwing); Mark Smith
> Cc: Brian E Carpenter; Fred Baker (fred); [email-masked]; 
> [email-masked]; [email-masked]; 

So - that means nobody cares about how to provision the CE router,
or it means we leave it to vendors, or we assume IPv4 will be used
to configure the CE router (e.g., the common 192.168.1.1), or is
the problem just that we lack a stable reference for mDNS?  I'm sure
you recall, between the time draft-wbeebee-v6ops-ipv6-cpe-router-bis-01
was posted (October 2009) and today, there was a long and active 
discussion on the main IETF list regarding Cheshire's multicast DNS;
would that discussion and its conclusion (whatever that may be) have
bearing on v6ops decision to pull mDNS from draft-ietf-v6ops-ipv6-cpe-router?

-d

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 6 Jan 2010 08:32:52 -0600

If IsRouter is FALSE, Linux will incorrectly garbage collect the
addresses, leading to lack of connectivity.

What mischief happens if the CE Router always sets IsRouter to TRUE on
both WAN and LAN interfaces?

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 Jan 2010 10:24:11 -0600

Fred,

It's a well-known problem in Linux that the OS incorrectly combined the
Neighbor Cache and the Destination cache causing data forwarding
failures and incorrect on-link assumptions.  This problem you are
alluding to about the IsRouter is another bug in the Linux code as to
why the OS has FIB clearing entries in the Neighbor Cache?  The FIB is
the Prefix List, the Destination Cache, and the Default Router List; the
FIB should not touch the Neighbor Cache.  I do grant you an OS can
independently garbage collect entries in the Neighbor Cache and the OS
is also not non-compliant for ND if the OS deletes entries in the
Neighbor Cache with IsRouter flag set to FALSE.  Note ND RFC 4861 does
not say anything about garbage collecting entries in the Neighbor Cache
with IsRouter flag set to FALSE.   

Now, when anyone reports a bug to me, I try to ascertain the severity of
the bug.  The issue you raise does not look severe to me,  It's a
temporary problem that can fix itself.  If an OS has this garbage
collection nuance and the Neighbor Cache entry is deleted, when the next
packet needs to be sent to the node whose entry was deleted in the SP
rtr, ND address resolution will take place and resolve the address
causing the Neighbor Cache to be populated again. ND also specifies the
packet be held in a queue till the packet's destination is resolved - so
the SP rtr is not likely to drop any packets.

Wes already asked, what if the CE Rtr always sets the IsRouter flag in
ND messages where this flag is possible to be set and that should take
care of your Linux problem.  If the CE Rtr sends an NA, the CE Rtr will
set the IsRouter flag to TRUE. 

Did we miss anything?

Thanks,

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 08:47:51 -0800

Wes,

> From: Wes Beebee (wbeebee) [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2010 6:33 AM
> To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred); [email-masked]

Linux will garbage collect FIB entries (not addresses)
but I'm not sure the behavior is incorrect. And yes,
this leads to lack of connectivity.

> both WAN and LAN interfaces?

The IsRouter flag associated with an interface (described
in Section 6.2.1) is distinct and different from the IsRouter
flag associated with neighbor cache entries (described in
Section 5.1). It seems odd that the same name (IsRouter) is
used for two different purposes in RFC4861, but the case we
are discussing is the latter (nbr cache entries).

But, the concern I have is for the IsRouter setting in 
SP router neighbor cache entries; not for IsRouter settings
in the CE router. The two are unrelated, and it is the
possibility of the SP router garbage collecting FIB
entries that concerns me.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 09:08:17 -0800

Hemant,

> Sent: Wednesday, January 06, 2010 8:24 AM
> why the OS has FIB clearing entries in the Neighbor Cache?

Not quite; the OS seems to clear *FIB entries* based on
the setting of the IsRouter flag in the neighbor cache
entry corresponding to the nexthop. The OS does not clear
entries in the nbr cache.

> The FIB is

No, I am not talking about garbage collecting *nbr cache*
entries based on IsRouter; I am talking about garbage
collecting *FIB entries* which can lead to loss of
connectivity. I have said this a number of times now.
Wes said it in his message, too.

> temporary problem that can fix itself.

Fix itself how? Once the FIB entry is gone there would
need to be some protocol for bringing it back and I don't
see that specified anywhere. And, unless the nbr cache
entry IsRouter flag gets set to TRUE, the FIB entry
could just be garbage collected all over again resulting
in the same loss of connectivity.

> If an OS has this garbage

See above - it is FIB entry deletion and not nbr cache
entry deletion that concerns me.

> set the IsRouter flag to TRUE.

I already said this both in an off-list message and more
recently on-list. If the CE router sends an RS, then the
SP router will set IsRouter in its nbr cache entry for the
CE router to FALSE. But, if the CE router subsequently
sends an NA message with the R bit (i.e., the Router bit)
set to TRUE, the SP router will set IsRouter in the nbr
cache entry to TRUE and the danger of FIB entry deletion
is averted.

Two problems with this however. First, it requires the
CE router to send a gratuitous NA message. Secondly,
the CE router has no way of knowing if the SP router
has received the NA message.

> Did we miss anything?

Yes, but I think I clarified it above?

Fred

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 6 Jan 2010 13:11:22 -0600

> Not quite; the OS seems to clear *FIB entries* based on the setting of
the IsRouter flag in the
> neighbor cache entry corresponding to the nexthop. The OS does not
clear entries in the nbr cache.

>From RFC 4861:

   "Router Solicitations in which the Source Address is the unspecified
   address MUST NOT update the router's Neighbor Cache; solicitations
   with a proper source address update the Neighbor Cache as follows.
...
   Whether or not a Source Link-Layer
   Address option is provided, if a Neighbor Cache entry for the
   solicitation's sender exists (or is created) the entry's IsRouter
   flag MUST be set to FALSE."

> But, if the CE router subsequently sends an NA message with the R bit
(i.e., the Router bit) set to
> TRUE, the SP router will set IsRouter in the nbr cache entry to TRUE
and the danger of FIB entry
> deletion is averted.

Well, the CE Router may need to receive an RA in order to know how to do
address acquisition on its WAN interface (doing SLAAC/DHCP, etc.).
Waiting for a periodic RA may not be feasible in some deployments, so a
CE Router MAY send an RS in order to increase the chances of receiving
an RA in a timely manner.  We don't want to block CE Routers from ever
sending RS's on their WAN interface.

Garbage collecting the FIB entries based on IsRouter value in the
Neighbor Cache is not specifically prohibited by RFC 4861 - so we're not
talking about a non-compliance issue.  

>From RFC 4861:

    "To limit the storage needed for the Destination and Neighbor
Caches,
     a node may need to garbage-collect old entries.  However, care must
     be taken to ensure that sufficient space is always present to hold
     the working set of active entries.  A small cache may result in an
     excessive number of Neighbor Discovery messages if entries are
     discarded and rebuilt in quick succession.  Any Least Recently Used
     (LRU)-based policy that only reclaims entries that have not been
used
     in some time (e.g., ten minutes or more) should be adequate for
     garbage-collecting unused entries.

     A node should retain entries in the Default Router List and the
     Prefix List until their lifetimes expire.  However, a node may
     garbage-collect entries prematurely if it is low on memory.  If not
     all routers are kept on the Default Router list, a node should
retain
     at least two entries in the Default Router List (and preferably
more)
     in order to maintain robust connectivity for off-link
destinations."

And, sending a gratuitous NA after an RA solely for the purpose of
preventing Linux running on the SP from GC'ing the CE Router entry has
the problems that you've already identified, and seems like a hack:

> Two problems with this however. First, it requires the CE router to
send a gratuitous NA message.
> Secondly, the CE router has no way of knowing if the SP router has
received the NA message.

I think the only other options are to say "don't GC if IsRouter is
FALSE" to Linux, which may not be an option if you run out of space, or
make sure that there's enough space that you don't GC more often than
you'd expect traffic from the CE Router to keep the entries alive, which
is already recommended by RFC 4861:

    "However, care must be taken to ensure that sufficient space is
always 
     present to hold the working set of active entries."

I think we've analyzed the problem fully now.  From a specification
standpoint, I don't know what you want us to do.  From a practical
implementation standpoint, I think you know what you're options are.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
Sent: Wednesday, January 06, 2010 12:08 PM
To: Hemant Singh (shemant); Fred Baker (fred); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: CPE router acting as host on its WAN interface (RE:
draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

Hemant,

> Subject: RE: CPE router acting as host on its WAN interface (RE: 
> draft-ietf-v6ops-ipv6-cpe-router- 03.txt WGLC)
> 
> Fred,
> 
> It's a well-known problem in Linux that the OS incorrectly combined 
> the Neighbor Cache and the Destination cache causing data forwarding 

Not quite; the OS seems to clear *FIB entries* based on the setting of
the IsRouter flag in the neighbor cache entry corresponding to the
nexthop. The OS does not clear entries in the nbr cache.

> The FIB is
> the Prefix List, the Destination Cache, and the Default Router List; 
> the FIB should not touch the Neighbor Cache.  I do grant you an OS can

> not say anything about garbage collecting entries in the Neighbor 
> Cache with IsRouter flag set to FALSE.

No, I am not talking about garbage collecting *nbr cache* entries based
on IsRouter; I am talking about garbage collecting *FIB entries* which
can lead to loss of connectivity. I have said this a number of times
now.
Wes said it in his message, too.

> Now, when anyone reports a bug to me, I try to ascertain the severity 
> of the bug.  The issue you raise does not look severe to me,  It's a 

Fix itself how? Once the FIB entry is gone there would need to be some
protocol for bringing it back and I don't see that specified anywhere.
And, unless the nbr cache entry IsRouter flag gets set to TRUE, the FIB
entry could just be garbage collected all over again resulting in the
same loss of connectivity.

> collection nuance and the Neighbor Cache entry is deleted, when the 
> next packet needs to be sent to the node whose entry was deleted in 
> the SP rtr, ND address resolution will take place and resolve the 
> address causing the Neighbor Cache to be populated again. ND also 
> specifies the packet be held in a queue till the packet's destination 
> is resolved - so the SP rtr is not likely to drop any packets.

See above - it is FIB entry deletion and not nbr cache entry deletion
that concerns me.

> care of your Linux problem.  If the CE Rtr sends an NA, the CE Rtr 
> will set the IsRouter flag to TRUE.

I already said this both in an off-list message and more recently
on-list. If the CE router sends an RS, then the SP router will set
IsRouter in its nbr cache entry for the CE router to FALSE. But, if the
CE router subsequently sends an NA message with the R bit (i.e., the
Router bit) set to TRUE, the SP router will set IsRouter in the nbr
cache entry to TRUE and the danger of FIB entry deletion is averted.

Two problems with this however. First, it requires the CE router to send
a gratuitous NA message. Secondly, the CE router has no way of knowing
if the SP router has received the NA message.

Fred

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Jan 2010 20:59:51 +0100

Fred,

the IsRouter flag only has value to a host, so that it can detect that
its default router is changing state from a router to a host. in this
scenario which is really a router-to-router link I cannot see any
problem with the service provider end getting the flag wrong. it is
after all not used for anything on a routed interface.

if an implementation deletes neighbor entries on a routed interface
based on a change in this flag, then that's a bug.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 Jan 2010 14:32:34 -0600

Fred,

For any further discussion, may I suggest using terminology from RFC
4861, otherwise we spend more time to understand each other.  I keep
saying the problem is temporary (yes, that is a pause in traffic flow)
and the problem will be fixed automatically but you send a reply back
saying "no the problem is not fixed automatically".  Also, my statements
are based on what I have been able to understand thus far from your
emails - this understanding may not be correct.  If you use the team
FIB, please define in terms of conceptual data structs defined in RFC
4861.  Wes tells me what you refer to as FIB is the Destination Cache.
But to me, the FIB is a collection of the Destination Cache, the Prefix
List, and the Default Router List.  Now we both think that what you call
as FIB is the routing table on the SP rtr.  Further, I believe what I
call as the Neighbor Cache, you refer to it as nbr. 

Now if a routing table entry is deleted from the SP Rtr, then it is
indeed a problem for which routing protocols are required.  However,
note that the SPs do not want any routing protocols between the CE Rtr
and the SP Rtr.  So then, really, it's a question of the SP Rtr be
designed properly as per SP Rtr quality standards and have its routing
table cache be sized appropriately. 

Please also note, if it's a routing table entry that got nuked, the
Conceptual Sending Algorithm of RFC 4861 does not apply to routing of
packets by the SP Rtr - the algorithm is applicable only to a host.
However, if the SP Rtr sources a packet destined to, say, a host behind
the CE Rtr, then the Conceptual Sending Algorithm is legal to use and
here is how it would work in your situation.  Let's say the Destination
Cache has the destination nuked. The Conceptual Sending Algorithm looks
up the destination in the Prefix List.  The Prefix List returns the
destination for the host behind the CE Rtr as off-link.  Then the
Neighbor Cache is looked up - since you said, the Neighbor Cache entry
is not nuked, the lookup succeeds and the packet is sent out and also a
Destination Cache entry is created. 

So again, as per Wes's email, the summary is still that this problem you
describe just needs a properly designed SP Rtr. Your problem does not
need any changes be made to the CE Rtr draft nor any changes to the ND
RFC nor any other RFC.

Thanks,

Hemant & Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 Jan 2010 14:50:08 -0600

Fred,

Humble apologies for missing one step in our description below.  Please
change the following text from our email

FROM:

"The Prefix List returns the destination for the host behind the CE Rtr
as off-link.  Then the Neighbor Cache is looked up - since you said, the
Neighbor Cache entry is not nuked, the lookup succeeds and the packet is
sent out and also a Destination Cache entry is created."

TO

"The Prefix List returns the destination for the host behind the CE Rtr
as off-link.  Then the Default Router List is looked up and that lookup
will succeed. Then the Neighbor Cache is looked up - since you said, the
Neighbor Cache entry is not nuked, the lookup succeeds and the packet is
sent out and also a Destination Cache entry is created."

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Wednesday, January 06, 2010 3:33 PM
To: Templin, Fred L; Fred Baker (fred); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: CPE router acting as host on its WAN interface (RE:
draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

Fred,

Thanks,

Hemant & Wes

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 12:46:54 -0800

Wes,

We are getting closer, but there are still a couple of
things to clarify:

> Sent: Wednesday, January 06, 2010 11:11 AM

I agree it is very likely that the CE router may need to
send a solicitation of some kind in order to receive a
more timely RA from the SP router.
 
> talking about a non-compliance issue.

Right.

>      in order to maintain robust connectivity for off-link

While this text is fine as quoted from the RFC, it does not
really apply to the issue we are discussing. We are concerned
with the case of an implementation garbage collecting FIB
entries based on the IsRouter setting in the neighbor cache
entry for the nexthop. This has nothing to do with memory
limitation, LRU, etc. - it is rather based on a policy
decision that routes not be allowed to use a non-router as
the next hop. 
 
>      present to hold the working set of active entries."

Again, this is not a memory limitation consideration; it is
a policy consideration. Linux is just one example of an OS
that seems to have adopted the policy of not allowing FIB
entries that use a non-router as the next hop. We don't
know what other implementations there are that might adopt
such a policy.

> standpoint, I don't know what you want us to do.

It seems that there needs to be some way to either
prevent the SP router from setting the IsRouter flag
to FALSE when the CE temporarily acts as a host or
to reset the flag to TRUE when the CE begins acting
as a router. I'm not sure there is a way to do either
of these without involving the SP router. 
 
> From a practical

I'm not sure I understand this part. This is an
operational consideration for which we see one
implementation that may be affected but we have
no way of knowing what other implementations
could be affected.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 13:07:32 -0800

Ole,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Wednesday, January 06, 2010 12:00 PM
> To: Templin, Fred L
> Cc: Fred Baker; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
> 
> Fred,
> 

Based on what I see in RFC4861, any interface that
maintains a neighbor cache (host or router) also manages
the IsRouter flag. 
 
> based on a change in this flag, then that's a bug.

It doesn't delete neighbor entries; it deletes FIB entries
(i.e., routes) that have a nexthop with IsRouter set to FALSE.

Fred

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 6 Jan 2010 15:36:10 -0600

> Again, this is not a memory limitation consideration; it is a policy
consideration. 

OK - I finally understand where you're coming from.  Consider the
following scenario:

1) A CE Router is connected via a link to a SP Router, and sends a
DHCPv6 SOLICIT with IA_PD.
2) An evil host running Dibbler sends a DHCPv6 SOLICIT with an IA_PD
option that SP router gleans.
3) SP router populates routing table with IA_PD from both boxes.
4) Traffic is sent to both the CE Router and the evil host destined for
PC's behind the CE Router and the evil host.
5) The evil host should NOT be receiving this traffic since it is not a
router.

Therefore, a policy was enacted to use the IsRouter flag to determine
whether the box is the CE Router or the evil host.  The evil host is
rejected by garbage collection (the policy).  Unfortunately, the CE
Router is also rejected by the policy, since the Neighbor Cache entry in
the SP Router says that the CE Router IsRouter flag is FALSE.

The policy is understandable from a security perspective.  However, the
primitive used to implement the policy (IsRouter) is too weak to do the
job.

There are two solutions to this problem.

1) Make IsRouter a stronger primitive that would be up to the job.
2) Use a different primitive which is stronger to implement the policy.

#1 is very difficult and may have serious repercussions to the ND
specification and other implementations and may not be feasible.

I suggest you start with #2.  Some primitives that may help (which have
other problems) include routing protocols, secure ND, DHCPv6 gleaning by
the SP Router, or a combination of the three.  

If these primitives are insufficient for your needs, you can consider
doing additional protocol work outside of the tools available in RFC
4861.

- Wes and Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 13:40:16 -0800

Hemant,

> Sent: Wednesday, January 06, 2010 12:33 PM
> as FIB is the routing table on the SP rtr.

Yes; I am referring to the routing table on the SP rtr;
the linux kernel calls this the FIB.

> Further, I believe what I

Almost - in the terminology I have used:

  nbr cache == Neighbor Cache
  nbr = Neighbor Cache Entry

I will try to stick as close as possible to RFC4861
terminology from now on.

> and the SP Rtr.

Yes, I understand that there are to be no routing
protocols between the CE and SP routers.

> So then, really, it's a question of the SP Rtr be
> designed properly as per SP Rtr quality standards

Where are those standards specified? And, do they say
that the SP router should ignore the IsRouter flag?

> and have its routing

Size is not the issue; policy is the issue.

> packets by the SP Rtr - the algorithm is applicable only to a host.

I'm not concerned about the Conceptual Sending Algorithm of a
host. I am concerned about what happens when the SP router
needs to forward a packet to a host behind a CE router, but
there is no route because the route was removed due to the
SP router thinking the CE router is a host.

> Destination Cache entry is created.

I saw your correction for this section, but this is not
the issue that concerns me. The issue that concerns me
is what happens if the SP router needs to forward a packet
to a host behind a CE router, but it doesn't have a route
because it mistakenly believes the CE router is a host.

> need any changes be made to the CE Rtr draft nor any changes to the ND

Somewhere it needs to be said that what you are calling
a "properly designed SP Rtr" needs to ignore the IsRouter
flag and not garbage-collect routes if IsRouter is FALSE.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jan 2010 14:04:16 -0800

Wes,

> Sent: Wednesday, January 06, 2010 1:36 PM
> To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred); [email-masked]

I don't know if it would be productive to try to guess
at what policy decisions the endless array of router
implementations would observe, but I know of at least
one implementation that takes heed of the IsRouter
flag when considering whether a route should be deleted.

> doing additional protocol work outside of the tools available in RFC

Maybe so, but lacking a spec I don't think it would
be productive to try to guess whether all router
implementations observe the same policies wrt the
IsRouter flag.

Fred

---

From: james woodyatt <[email-masked]>
Date: Wed, 6 Jan 2010 17:15:57 -0800

> I'm inclined to think we should take the Route Information Option from RFC 4191 and define a way to add it to the Neighbor Advertisement message.

Well, this was an embarrassingly dumb thing for me to have written, and after a brief coffee break, I decided I should come forward and admit it.  Forget I wrote this.  Not smart.  Ooops.

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Wed, 6 Jan 2010 20:08:49 -0500

> that the SP router should ignore the IsRouter flag?

Telcos will create the SP Router standards in the BBF, more than likely.
I wouldn't be surprised if CableLabs did standards for the cable
companies, but I have no direct knowledge of that. My guess is that the
BBF standards won't even mention the IsRouter flag. There will be no NS
or RS messages sent to CE routers (or hosts). So there will be no
solicited NA or RA messages coming from the CE routers. The current
requirement for CE routers supplied by BBF SPs is that they will never
send RA messages out the WAN interface, solicited or unsolicited (WAN
interface is not an advertising interface). No mention has been made of
unsolicited NA messages, so far. This is probably because no-one
realistically expects to see unsolicited NA messages. If people are
thinking about really implementing unsolicited NA, then I think it may
be necessary to say that they're undesirable.

I think that Wes and Hemant are correct in assuming that this IsRouter
flag thing will be a non-issue in SP Routers.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Jan 2010 11:53:52 +0100

Dan,

thanks for extensive comments!

[removed DNS comment. as I have nothing to add. I'd really like a consensus coming out of v6ops/behave for any new or different CPE requirements]

> in Section 4.2 and some of the L-* requirements.

agree. added your proposed text in section 3.1

> offering service to students in University housing.  Is that intentional?

<t hangText="Service Provider">an entity that provides
          access to the Internet. In this document, a Service Provider
          specifically offers Internet access using IPv6, and may also
          offer IPv4 Internet access. The Service Provider can provide
          such access over a variety of different transport methods
          such as DSL, cable, wireless, and others.</t>

is the above text any better? "entity" is quite fluffy, but what can you do...

> RFCxyz, except L-5c and L5-d".

I agree with this suggestion.

Best regards,
Ole

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 08:28:51 -0800

> From: Ole Troan [mailto:[email-masked]] 
> Sent: Thursday, January 07, 2010 2:54 AM
> To: Dan Wing
> Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC
> 
> Dan,
> 
> [removed DNS comment. as I have nothing to add. I'd really 
> like a consensus coming out of v6ops/behave for any new or 
> different CPE requirements]
> 

Works for me.  Thanks.

> provide ULA

-d

---

From: "Chris Donley" <[email-masked]>
Date: Thu, 7 Jan 2010 09:50:00 -0700

Barbara is correct - CableLabs includes some router requirements in our
DOCSIS 3.0 specifications, and we do not mention the IsRouter flag.  We
will support a number of different routed network topologies (e.g.
router embedded in a cable modem or standalone router), and have
specified different policy enforcement mechanisms (not IsRouter) to
determine which devices should receive prefix delegations and which
traffic should be filtered.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of STARK, BARBARA H (ATTLABS)
Sent: Wednesday, January 06, 2010 6:09 PM
To: Templin, Fred L; Hemant Singh (shemant); Fred Baker (fred);
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: CPE router acting as host on its WAN interface (RE:
draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA622

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 7 Jan 2010 12:25:56 -0600

>From: STARK, BARBARA H (ATTLABS) [mailto:[email-masked]] 
>Sent: Wednesday, January 06, 2010 8:09 PM
[email-masked]

>companies, but I have no direct knowledge of that. 

That is correct.  CableLabs has defined the standards for the IPv6 Cable
Router in their network with no mention of the IsRouter flag.

>My guess is that the BBF standards won't even mention the IsRouter
flag. There will be no NS
>or RS messages sent to CE routers (or hosts). 

Hmm, why won't a SP Rtr send an NS to the CE Rtr?  For one, the SP Rtr
can send an NS to resolve the link-local or global of the WAN interface
of the CE Rtr.

>So there will be no solicited NA or RA messages coming from the CE
routers. 

The CE Rtr can send an NA in response to the NS I mentioned above.

Hemant

---

From: Konrad Rosenbaum <[email-masked]>
Date: Fri, 8 Jan 2010 14:35:32 +0100

Hi,

I'm trying to confirm this route-loss-problem.

> addresses, leading to lack of connectivity.

What specific version of Linux is this? I just took a walk through the IPv6 
code in Linux 2.6.26 (Debian kernel) and did some experiments with it. I 
could not find the problem. Although I must admit I'm not a kernel expert.

Yes, the fib6_age function in ip6_fib.c under some circumstances deletes 
cached routes via non-routers (gateways), but there is a difference between 
the FIB main (routing) table and the FIB cache (shortcuts for already 
resolved walks through the main table - it is just a speedup table). The 
entries established during CE-SP handshake will reside in the main table, 
which is not affected. The only collection that happens in the main table 
is timer based (based on the timeout given in RAs).

Experiment:
SP - a server running pppoe-server, with RAdvD and some DHCP server
CE - my makeshift router, running pppoe-client and a simple Ethernet
Host - a simple host on the Ethernet to CE

[SP] <--PPP-link--> [CE] <--Ethernet--> [Host]

The ethernet was setup manually with default route towards CE, so no 
collection here. If I took the steps to setup RAdvD on it, RAs would keep 
everything alive. So no issue either way.

The SP is set up to be router on all interfaces.

The CE is host on PPP and router on Ethernet.

The Host is host.

On the CE the PPP-link is setup in this order: IPCPv6, (automatic) RS-RA, 
optionally DHCP-IAPD which would configure the IP addr and RAdvD for the 
Ethernet, if it honours timeouts it will repeat the process in time. The 
PPP-link and its routes will be kept alive through RA's from the SP, or 
regular RS-RA-pairs. Nothing strange happens...

The SP side of the PPP-link is configured from the PPP scripts. Which means 
manual routes, which do not get collected at all until the link goes down.

I waited for all the timeouts to run out (a few minutes on my setup) and the 
FIB caches to clear (less than a minute). But I could still ping from 
anywhere in my setup to anywhere else in it. Actually the FIB cache was not 
even used for PPP links.

In conclusion: unless I completely and intentionally screw up the setup 
manually, both links will always have complete routes on either end. The 
only difference after FIB cache garbage collection is that the first ping 
packet needs 10ms instead of 5ms.

Did I miss the scenario?

> both WAN and LAN interfaces?

The CE would shoot itself squarely into the foot: since it does not do a RS 
on the PPP-link, it will never know about its on-link prefix and will set 
some routes wrongly (which would need to be corrected manually). I wasn't 
even able to get pings to route from Host to SP if the CE had its ppp-link 
configured as router.

	Konrad

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2010 09:56:32 -0800

Konrad,

It was excellent for you to have performed such a thorough
investigation, but the high-order consideration is this:

> cached routes via non-routers (gateways),

Here, we have an implementation (linux kernel) that is
widely used as the basis for router products, and that
takes action based on the setting of the IsRouter flag
in neighbor cache entries. Linux is operating outside
the letter of the RFC4861 law in this regard, and if
Linux is making its own interpretation (no matter how
innocuous) then other implementations may be making
their own interpretations which may not be so innocuous.

Therefore, there needs to be a warning label.

Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Konrad Rosenbaum
> Sent: Friday, January 08, 2010 5:36 AM
> To: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Sun, 24 Jan 2010 23:31:41 +0100

hi,

here is a summary of the issues raised during the last call of this document.

in addition to a few spelling errors and nits we have received the
following comments:

- use DHCPv6 instead of DHCP
  => accepted.
- move the "general requirements" to the top
  => accepted
- change the generic MUST for PPP and Ethernet to "if supported"
  => accepted
- remove reference to PPPoE
  => accepted
- split requirements. especially those which have both MUST and SHOULD
  => accepted
- discussion on the hint given in a PD request- what to do if CE
doesn't get a large enough prefix from PD
  => accepted: clarified text in the requirement.
- what to do if the prefix 'hinted' at isn't large enough?
  => accepted: added text to say that SHOULD raise a system management error.
- discussion on how IPv6 only / DS stack hosts should work with
NAT64/DNS64 and this draft
  => rejected: nothing we can do within scope of this draft
- some discussion on use of ND and prefix redirection and routing on
WAN side interfaces
  => rejected: not in scope
- isRouter flag confusion when CE router is acting as a host
  => rejected: not considered problematic

we have just posted revision 04 which includes the above issues and
the nits we received during the last call.

Best regards,
Ole

On Mon, Jan 4, 2010 at 4:45 PM, Fred Baker <[email-masked]> wrote:
> 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.
>
>
>
>
> This draft is a work item of the IPv6 Operations Working Group of the IETF.
>
>