Subject: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

From: [email-masked]
Date: Sat, 05 Mar 2011 10:45:02 -0800

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           : Advanced Requirements for IPv6 Customer Edge Routers
	Author(s)       : H. Singh, et al.
	Filename        : draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt
	Pages           : 16
	Date            : 2011-03-05

This document continues the work undertaken by the IPv6 CE Router
Phase I work in the IETF v6ops Working Group.  Advanced requirements
or Phase II work is covered in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-bis-00.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.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2011 09:41:25 +1300

Hi,

> 3.  Conceptual Configuration Variables
> 
>    The CE Router maintains such a list of conceptual optional
>    configuration variables.
> 
>    1.  Enable an IGP on the LAN.

This section seems very strange with just one item sitting
there on its own, and no discussion in the draft of which
IGPs are candidates for support.

> 5.1.  DNS
> 
>    D-1:  For local DNS queries for configuration, the CE Router MAY
>          include a DNS server to handle local queries.  

What is the reason to include the words "for configuration"?

What is the meaning of "local queries"? Is this intended to imply that
there are names such as printer1.example.com that are only meaningful
and visible "inside" the CPE boundary? If so, what is the domain name?
Is the CPE supposed to know an appropriate domain name and if so, how?

>    D-2:  The local DNS server MAY also handle renumbering from the
>          Service Provider provided prefix for local names used
>          exclusively inside the home (the local AAAA and PTR records are
>          updated).  This capability provides connectivity using local
>          DNS names in the home after a Service Provider renumbering.  A

This is the only mention of renumbering in the draft. Is renumbering support
a goal? If so, please look at draft-jiang-ipv6-site-renum-guideline.
It is clearly not enough to just mention it as part of DNS support.

>          CE Router MAY add local DNS entries based on dynamic requests
>          from the LAN segment(s).  The protocol to carry such requests
>          from hosts to the CE Router is yet to be described.

Surely it should be RFC 3007?

>    LNDP-1:  If the CE Router has only one /64 prefix to be used across
>             multiple LAN interfaces and the CE Router supports any two
>             LAN interfaces that cannot bridge data between them because
>             the two interfaces have disparate MAC layers, then the CE
>             Router MUST support Proxying Neighbor Advertisements as
>             specified in Section 7.2.8 of [RFC4861].  If any two LAN
>             interfaces support bridging between the interfaces, then
>             Proxying Neighbor Advertisements is not necessary between
>             the two interfaces.  Legacy 3GPP networks have the following
>             requirements:

There needs to be a paragraph break before "Legacy 3GPP..."

Just below:

>             4.  No NAT66 is to be used.

Is this referring to NPTv6 or something else? It's important to be
clear, since trying to stop stateful NAPT66 is one battle, and trying to
stop NPTv6 is another.

>    The IPv6 CE Router SHOULD implement DS-Lite functionality as
>    specified in [I-D.ietf-softwire-dual-stack-lite].
...
>    The IPv6 CE Router SHOULD implement 6rd functionality as specified in
>    [RFC5969].

I'm really not sure about these SHOULDs. It's not they are bad things to include,
but there may be situations where they are insufficient and some other
form of tunnel is needed. At the very least say that other backhaul tunnel
mechanisms MAY be supported, without specifying them. Then add a corresponding
point in the next section:

> 5.5.3.  Transition Technologies Coexistence
> 
>    Run the following four in parallel to provision CPE router
>    connectivity to the Service Provider:
> 
>    1.  Initiate IPv4 address acquisition.
> 
>    2.  Initiate IPv6 address acquisition as specified by
>        [I-D.ietf-v6ops-ipv6-cpe-router].
> 
>    3.  If 6rd is provisioned, initiate 6rd.
> 
>    4.  If DS-Lite is provisioned, initiate DS-Lite.

  If this procedure fails, some other form of tunnel MAY be initiated.

Also, I think section 5.5.3 should recommend that the CPE be configurable
to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is
available.

> 6.  Security Considerations
> 
>    None.

I think you need a few more words there, e.g.

This document introduces no security concerns that are
not discussed in the referenced specifications.

Finally,  idnits shows about 20 unused references.

Regards
   Brian Carpenter

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 13 Mar 2011 21:08:14 -0500

Brain,

Thanks much for the review.  I have responded to some of your comments
below.  Will send another email replying to your other comments.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Sunday, March 13, 2011 4:41 PM
To: [email-masked]
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>IGPs are candidates for support.

The section is a placeholder for any more variables to be added in
future.  Anyway, the document shies away from recommending any specific
IGP in the LAN to avoid religious wars for one's favorite IGP.  Old IPv4
routers do support RIP, so one IGP we could recommend is RIPng.  However
soon as we recommend RIPng, someone will say, no, they want OSPFv3.
That is why the document is silent on what specific IGP.

>What is the reason to include the words "for configuration"?

By configuration we mean accessing the CE router using http.  Further
some other auto-configuration of the CE router in the routed LAN domains
is also possible if the CE router supports a recursive DNS server.  Note
zeroconf works only in the IPv6 link-local domain. 

>It is clearly not enough to just mention it as part of DNS support.

RFC 3633 is already specified in the Basic IPv6 CE Router document and
RFC 3633 discusses using the DHCPv6 Reconfigure message for renumbering.
Thus this Advanced document does not discuss any more renumbering.
However, since DNS was not included in the IPv6 CE Router document and
DNS is impacted by renumbering, we have provided some text.   Also, the
document tries to avoid proposing any solution that is in draft form; we
try and include solutions in RFC form.  Thanks for the draft reference
though.  I will look at it.

>There needs to be a paragraph break before "Legacy 3GPP..."

Agreed.

>not discussed in the referenced specifications.

Agreed.  Will add some text.

>Finally,  idnits shows about 20 unused references.

We will remove these unused references.

Thanks much,

Hemant

---

From: Michael Newbery <[email-masked]>
Date: Mon, 14 Mar 2011 16:42:25 +1300

> or Phase II work is covered in this document.

The diagram and the text do not seem to allow explicitly for multihoming to more than one service provider.

You refer to an IGP (only) in section 3.1. If the CPE router is not multihomed, why bother running an IGP on it at all? It is unlikely that the service provider will listen to any routing advertisements you generate. There is only a binary choice for the default route: it's there or it isn't, and that can be propagated to the LAN without needing a full IGP.

If you do allow for mulithoming though, then the CPE router surely needs to run BGP----and have rather a lot of memory :)

>          include a DNS server to handle local queries.  Non-local
>          queries can be forwarded unchanged to a DNS server specified in
>          the DNS server DHCPv6 option. 
If the intent was to handle ".local", I thought that this was in conflict with mDNS as it is generally implemented. If the intent is to optional offer a lightweight DNS server built into the CPE-router then I think that's what should be stated in the RFC, explicitly. And is that's the case, what are its constraints?  Is it authoritative for the user's home domain (with all that implies); is is a caching only server; is it a stealth server; is it a hidden primary?

If however the desire is simply ".local" service, then why not just suggest mDNS, possibly with provision for static entries to support devices that can't do mDNS themselves.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Mar 2011 09:21:17 -0500

-----Original Message-----

Brian,

>Is the CPE supposed to know an appropriate domain name and if so, how?

"local" means the CE Router replies to queries from the LAN rather than
forwarding the query as a recursive DNS server.  The domain name can be
provisioned via a DHCPv6 option from the SP or manually.  

>clear, since trying to stop stateful NAPT66 is one battle, and trying
to

We can clarify this bullet and remove the use of the term NAT66.   What
we mean is any of network port or address translation
(stateful/stateless) is not used. 

>point in the next section:

The SP's on the CE router design team (they are contributors to the
document) did not want DS-Lite nor 6rd as a MUST in the document.  Thus
the "SHOULD" came about. 

>  If this procedure fails, some other form of tunnel MAY be initiated.

Section 5.5.3 has each mechanism try forever.  Thus how does one detect
failure to then try another tunneling mechanism?  

>to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is

The same section also specifies routing prefers a default route over
native transport vs. tunneled transport and thus whenever any mechanism
succeeds, data forwarding is appropriately adjusted for default route
preference.  Why is there any need to block anything?

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Mar 2011 12:12:08 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Newbery
Sent: Sunday, March 13, 2011 11:42 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>The diagram and the text do not seem to allow explicitly for
multihoming to more than one service provider.

Yes, the reason is because multihoming is not supported for a feature by
the document.

>You refer to an IGP (only) in section 3.1. If the CPE router is not
multihomed, why bother running an IGP on it at all?

The IGP is also mentioned in section 5.4.  If the IGP is not run in the
home LAN, how does a router upstream learn about routes in the
downstream if the LAN topology is a graphed routed network?

> It is unlikely that the service provider will listen to any routing
advertisements you generate. There is only a binary choice for the
default route: it's there or it isn't, and that can be propagated to the
LAN without needing a full IGP.

Not quite.  If a simple recursive prefix delegation in the LAN is used
(with only a tree routed) topology, the routes across various routers
are known because upstream routers have aggregated the delegated prefix
route.  But a non-tree routed topology for which a graph is the most
general case, one will need IGP.    However, you do have one point.  If
the document only supports a specific two-router topology, then there is
no graphed network and an IGP is not needed.   We still decided to keep
the IGP in section 5.4 to support the future work if any generic routed
case and multihoming get taken up for work.

	>         include a DNS server to handle local queries.
Non-local

>If the intent was to handle ".local", I thought that this was in
conflict with mDNS as it is generally implemented. If the intent is to
optional offer a lightweight DNS server built into the CPE-router then I
think that's what should be stated in the RFC, >explicitly. And is
that's the case, what are its constraints?  Is it authoritative for the
user's home domain (with all that implies); is is a caching only server;
is it a stealth server; is it a hidden primary?

Since the document does not mention a recursive DNS server, the device
is expected to support a DNS proxy which by definition does not cache.
The configuration needed with DNS is so that a user can use http to a
name such as route.local.    There is no need for mDNS for such basic
http configuration.   

>If however the desire is simply ".local" service, then why not just
suggest mDNS, possibly with provision for static entries to support
devices that can't do mDNS themselves.

Certainly it makes sense for us to mention static entries which is
manual configuration.  I mentioned manual configuration in my reply to
Brian Carpenter comments.   We will work the DNS section some more and
clarify issues.

Thanks much,

Hemant

---

From: james woodyatt <[email-masked]>
Date: Mon, 14 Mar 2011 10:27:32 -0700

On Mar 14, 2011, at 10:12 AM, Hemant Singh (shemant) wrote:
> 
> We still decided to keep the IGP in section 5.4 to support the future work if any generic routed case and multihoming get taken up for work.

This is a bad idea.  If we don't have clear guidance on an IGP to give to equipment makers, and we don't, then we shouldn't say anything about an IGP in this draft.  You run the risk equipment makers will ignore the whole document by including stuff like this.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Mar 2011 12:49:56 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Monday, March 14, 2011 1:28 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>This is a bad idea.  If we don't have clear guidance on an IGP to give
to equipment makers, and we don't, then we shouldn't say anything about
an IGP in this draft.  You run the risk equipment makers >will ignore
the whole document by including stuff like this.

Two IGPs we could propose are RIPng and OSPF with all area 0.  However
vendors will ask which one IGP do we support if we support only one? So
now what do we do?  Also, what would SP's have to say, if anything,
about an IGP in the LAN?   

Thanks,

Hemant

---

From: james woodyatt <[email-masked]>
Date: Mon, 14 Mar 2011 11:12:21 -0700

On Mar 14, 2011, at 10:49 , Hemant Singh (shemant) wrote:
> 
> Also, what would SP's have to say, if anything, about an IGP in the LAN?

This, right here, is the reason this whole residential routing domain thing is a tiger's tail.  The V6OPS working group should leave it alone.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 Mar 2011 19:13:50 +0100 (CET)

> now what do we do?  Also, what would SP's have to say, if anything, 

As an SP, I don't really care. My handoff to the customer is going to be 
DHCPv6-PD induced static route without any routing protocol.

As a home user, I want efficient routing so an IGP would definitely be 
nice. I just want it to work. RIPng and OSPF both works for me, but I 
think we should pick one, not two.

Vendors who would implement this, what do you prefer of these two?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Mar 2011 11:58:45 -0700

Good grief. Any residential IPv4 gateway worthy of the name supports at least the version of RIP we obsoleted when we adopted CIDR. The SMC one below describes itself as an "Ethernet Switch", which usually means "802.1d" and not a lot more, but it supports RIP. If we can't specify that an industry that figured out for itself that RIP existed and was a market requirement for them in IPv4 should implement RIPng (RFC 2080/2081) for IPv6, we deserve to be ignored.

No, this has nothing to do with service providers, although some of the ones below are "managed gateways", which is to say a residential CPE sold and/or operated by an ISP. This is about residential networking equipment.

I looked up http://ipv6.google.com/q=broadband+router, and from that http://compnetworking.about.com/od/broadband/tp/dslcablerouters.htm to get a list of residential router manufacturers. The ones I came up with were SMC, Netgear, Multitech, Asante, Linksys, 2Wire, US Robotics, D-Link, and Nexland. I found another vendor by accident in the process, and I probably missed several. I then executed http://ipv6.google.com/#hl=en&q=VENDOR-NAME+RIP+routing

open 'http://ipv6.google.com/#hl=en&q=SMC+RIP+routing' 
◆ Routing features: IP/RIP routing, CIDR 
http://www.smc.com/files/AG/MN_SMC88xxM_MNG.pdf

open 'http://ipv6.google.com/#hl=en&q=Netgear+RIP+routing' 
RIPv1 and RIPv2
http://documentation.netgear.com/dgfv338/enu/202-10161-01/DGFV338_RM-09-08.html

open 'http://ipv6.google.com/#hl=en&q=Multitech+RIP+routing' 
Supports RIPv1
http://reviews.cnet.com/routers/multi-tech-routefinder-router/1707-3319-30046399.html

open 'http://ipv6.google.com/#hl=en&q=Asante+RIP+routing' 
Supports Layer 3 Routing for IP with Router Standby Protocol, Router Discovery Protocol, RIP I/II, OSPF, including static route table (insertion/deletion) and Layer 3 IGMP multicasting 
http://www.asante.com/downloads/datasheets/IntraCore/IC35516_DS.pdf

open 'http://ipv6.google.com/#hl=en&q=Linksys+RIP+routing' 
Supports static routes, RIPv1 and RIPv2 
http://ui.linksys.com/files/WAG200G/1.00.09/help/h_AdvRouting.htm

open 'http://ipv6.google.com/#hl=en&q=2Wire+RIP+routing' 
Apparently does not support RIP

However (google is wise and took me here...?)
Corecess supports  RFC 1058 RIP v1, RFC 1723 RIP v2. 
http://www.corecess.com/eng/product/xdsl_corecess3300.asp

open 'http://ipv6.google.com/#hl=en&q=Robotics+RIP+routing' 
Supports static routes, RIPv1 and RIPv2 
http://www.usr.com/support/9108/9108-ug/wui_lan.htm#option7

open 'http://ipv6.google.com/#hl=en&q=D-Link+RIP+routing' 
Supports static routes, RIPv1 and RIPv2 
http://screenshots.portforward.com/Dlink/DSL-2640B_SEA_1.00/Routing_RIP.htm

open 'http://ipv6.google.com/#hl=en&q=Nexland+RIP+routing' 
Supports static routes and RFC 1058 RIP 
http://68.67.73.20/routers/nexland-pro400-broadband-router-with-a-built-in-161

The only one that doesn't also calls itself a "modem".

On Mar 14, 2011, at 10:49 AM, Hemant Singh (shemant) wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 14 Mar 2011 12:11:22 -0700

On 3/14/11 11:12 AM, james woodyatt wrote:
> This, right here, is the reason this whole residential routing
> domain thing is a tiger's tail.  The V6OPS working group should leave
> it alone.

except in the case where the cpe is literally a bridge, I see no reason
why the service provider would have any interest at all unless they're
managing the interior network as well.

> 
> -- james woodyatt <[email-masked]> member of technical staff, core os 
> networking
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2011 09:10:07 +1300

> managing the interior network as well.

Exactly. If the ISP has delegated a /56 (or whatever) to the CPE, it
has absolutely no interest in the local topology that the CPE supports,
therefore absolutely no interest in the IGP.

I think I'm with Fred - suggest RIPng as a MAY implement. There's no reason
to make it a SHOULD, and vendors will presumably know what their market
wants.

OSPF is for a different class of device anyway.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 14 Mar 2011 13:22:52 -0700

On Mar 14, 2011, at 13:10 , Brian E Carpenter wrote:
> 
> I think I'm with Fred - suggest RIPng as a MAY implement. There's no reason to make it a SHOULD, and vendors will presumably know what their market wants.

I would oppose making it a SHOULD recommendation.  I wouldn't object to MAY.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2011 09:26:32 +1300

> provisioned via a DHCPv6 option from the SP or manually.  

Er, how does that work, if a host resolves printer11.example.com that
doesn't happen to exist? A local resolver can only recurse such a query,
because it has no way to know that it's intended to be local.

This simply is not described well enough to make sense. As others have noted,
you have to decide - is it genuine DNS, or a .local/mDNS style of kludge?

If it's genuine DNS you have to recurse.

If the idea is to recommend a DNS kludge, you'l have a very interesting
discussion in IETF Last Call.

> (stateful/stateless) is not used. 

Do you really think that is viable? Trying to forbid NPTv6 is really
spitting into the wind. What you can say safely is that any form of network
port or address translation is not necessary.

> document) did not want DS-Lite nor 6rd as a MUST in the document.  Thus

Agreed, a MUST would be unreasonable.

> failure to then try another tunneling mechanism?  

That's a bug. We can't publish a model that makes other mechanisms
impossible, because there may be situations where they are appropriate.

You can say that other forms of tunnel MAY be supported and if so
they SHOULD be included in the trial and error loop.

> preference.  Why is there any need to block anything?`

Protocol 41 is a special case. The IPv6 routing will not see v6-in-v4
traffic and the IPv4 routing will just route it.

You can see draft-carpenter-v6ops-6to4-teredo-advisory for one aspect
of this, but once you have native (or 6rd) support of IPv6, you need to
block all Protocol 41 methods through the CPE.

   Brian

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 14 Mar 2011 13:42:01 -0700

We do need to select one IGP.  I don't really care if it is RIP or OSPF.

Support for the IGP should be a MUST or it is fairly pointless.

On 3/14/11 1:22 PM, "james woodyatt" <[email-masked]> wrote:

>> I think I'm with Fred - suggest RIPng as a MAY implement. There's no
>>reason to make it a SHOULD, and vendors will presumably know what their
>>market wants.
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 14 Mar 2011 16:36:34 -0700

> discussion in IETF Last Call.

Now is probably a good time to mention that one of the ways AirPort and Time Capsule split the DNS horizon is by refusing to forward unicast queries for the "local" TLD.

It might make sense if the resolving server used mDNS on the LAN bridge to resolve such queries and sent all the answers it receives in a reasonable amount of time back in a single response.  The trouble is deciding what is a "reasonable" time.

For the sake of expediency, at Apple, we just made the DNS forwarding server respond to such queries with NXDOMAIN, which is probably the wrong RCODE value, but it was the lowest risk way to solve an immediately pressing problem (which I'm not at liberty to disclose here) related to a consequence of forwarding such queries improperly.

Suffice to say, some applications may inappropriately expect that the "local" TLD is resolved *only* by mDNS and not by unicast DNS, and they may, as a consequence, adopt an insufficiently strong security profile based on the faulty assumption that on-link destination addresses are the only ones that can ever be returned from such queries on mDNS-capable hosts.  Protecting faulty applications from disclosing local information over the WAN may require splitting the DNS horizon in this way.

I think I might recommend that CPE routers not forward DNS queries for the "local" TLD.  They should probably return RCODE=5 (REFUSED).

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Mar 2011 16:58:28 -0700

> I think I might recommend that CPE routers not forward DNS queries for the "local" TLD.  They should probably return RCODE=5 (REFUSED).

Would that be at all like any of the following?

http://tools.ietf.org/html/draft-bpw-pcp-dhcp
  "DHCP and DHCPv6 Options for Port Control Protocol (PCP)", Mohammed
  Boucadair, Reinaldo Penno, Dan Wing, 2-Mar-11,
  <draft-bpw-pcp-dhcp-03.txt>

http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd
  "DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal,
  27-Feb-11, <draft-cheshire-dnsext-dns-sd-10.txt>

http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns
  "Multicast DNS", Stuart Cheshire, Marc Krochmal, 14-Feb-11,
  <draft-cheshire-dnsext-multicastdns-14.txt>

http://tools.ietf.org/html/draft-cheshire-dnsext-nbp
  "Requirements for a Protocol to Replace AppleTalk NBP", Stuart Cheshire,
  Marc Krochmal, 12-Jan-11, <draft-cheshire-dnsext-nbp-10.txt>

http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones
  "Locally-served DNS Zones", Mark Andrews, 21-Sep-10,
  <draft-ietf-dnsop-default-local-zones-14.txt>

http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package
  "An Interactive Voice Response (IVR) Control Package for the Media
  Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris
  Boulton, 6-Jan-11, <draft-ietf-mediactrl-ivr-control-package-11.txt>

http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists
  "Overview of Email DNSBL Best Practise", Chris Lewis, Matt Sergeant,
  11-Mar-11, <draft-irtf-asrg-bcp-blacklists-08.txt>

http://tools.ietf.org/html/draft-iulian-advanced-groupware-access-protocol
  "Advanced Groupware Access Protocol", Iulian Radu, 14-Nov-10,
  <draft-iulian-advanced-groupware-access-protocol-02.txt>

http://tools.ietf.org/html/draft-kiesel-alto-3pdisc
  "ALTO Server Discovery Protocol", Sebastian Kiesel, Marco Tomsu, Nico
  Schwan, Michael Scharf, Martin Stiemerling, 25-Oct-10,
  <draft-kiesel-alto-3pdisc-04.txt>

http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns
  "Extended Multicast DNS", Kerry Lynn, Don Sturek, 7-Mar-11,
  <draft-lynn-dnsext-site-mdns-00.txt>

http://tools.ietf.org/html/draft-salgueiro-sipclf-indexed-ascii
  "Format for the Session Initiation Protocol (SIP) Common Log Format
  (CLF)", Gonzalo Salgueiro, Vijay Gurbani, Adam Roach, 5-Mar-11,
  <draft-salgueiro-sipclf-indexed-ascii-03.txt>

http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis
  "Advanced Requirements for IPv6 Customer Edge Routers", Hemant Singh,
  Wes Beebee, Chris Donley, Barbara Stark, Ole Troan, 25-Oct-10,
  <draft-wbeebee-v6ops-ipv6-cpe-router-bis-04.txt>

http://tools.ietf.org/html/draft-xwwang-ipv6-tesf
  "TESF Based on True IPv6 Address Access", Xingwei Wang, ZhanKao Wen, Jun
  Liu, WeiDong Wang, PengCheng Liu, 7-Nov-10,
  <draft-xwwang-ipv6-tesf-00.txt>

http://tools.ietf.org/html/draft-xwwang-ipv6tesf
  "TESF Based on True IPv6 Address Access", Xingwei Wang, ZhanKao Wen,
  WeiDong Wang, Jun Liu, PengCheng Liu, 23-Dec-10,
  <draft-xwwang-ipv6tesf-00.txt>

?

---

From: Michael Newbery <[email-masked]>
Date: Tue, 15 Mar 2011 15:43:39 +1300

> discussion in IETF Last Call.

One would include a DNS in the CPE router for three reasons:
1. As a full blown DNS server, authoritative for the customer's zone
2. As a cache, in order to speed up DNS resolution
3. In order to supply local name resolution, so the user doesn't have to type in raw IPv6 addresses.

These reasons are not necessarily mutually exclusive.

I question the need for (1). I especially question the need for it in the RFC. If a manufacturer wishes to bundle a full blown DNS server in their CPE, that's a marketing decision.

I question the need for (2). Experience with the Google DNS namebench <http://code.google.com/p/namebench/> has shown evidence that local DNS caching just slows down performance.

I fully agree with (3). But personally I would have thought that mDNS was a better for to this particular need.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 06:03:10 +0100 (CET)

On Tue, 15 Mar 2011, Michael Newbery wrote:

> I fully agree with (3). But personally I would have thought that mDNS 
> was a better for to this particular need.

So a local resolver basically isn't needed and may be a MAY requirement?

The major reason not to have one is that a lot of the time, it seems 
vendors get it wrong and the local resolver causes harm instead of 
benefit.

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Mar 2011 21:34:23 +1030

On Tue, 15 Mar 2011 15:43:39 +1300

> I question the need for (1). I especially question the need for it in the RFC. If a manufacturer wishes to bundle a full blown DNS server in their CPE, that's a marketing decision.

I think there is value in this, if mDNS and DNS-SD is also available.
This would allow ISPs to delegate e.g. <username>.cust.<ISP.com> and
the delegated prefix reverse to the CPE. The customer could then use
DNS-SD and optionally mDNS to populate their delegated domain. 

> I fully agree with (3). But personally I would have thought that mDNS was a better for to this particular need.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Mar 2011 21:47:25 +1030

On Tue, 15 Mar 2011 06:03:10 +0100 (CET)

> vendors get it wrong and the local resolver causes harm instead of 

A possible advantage of a local resolver would be that if it received
both A and AAAA RRs (over IPv4) and the WAN interface didn't support
IPv6, it could avoid supplying the AAAAs to ULA IPv6 connected
end-nodes on it's LAN interfaces. 

I'm not completely sure, however I think a drawback is that if a new RR
type is added, the DNS resolver has to be upgraded to support it (or
has my knowledge of DNS just failed - is it possible to issue and cache
results of queries for unknown RRs?). I'm encountering this sort of
issue with stateless DHCPv6 servers on CPE LAN interfaces - I'm starting
to think the LAN interface of a CPE sould be a DHCPv6 relay towards an
off-site stateless DHCPv6 server, with the stateless DHCPv6 server's
IPv6 address supplied with an option during the stateful DHCPv6
delegated prefix transaction, if the stateless DHCPv6 server's address
isn't the same as the Delegated Prefix DHCPv6 server. That would avoid
a CPE's DHCPv6 option implementation restricting what options the
end-nodes can use.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Mar 2011 12:41:19 +0100

Hi,

> end-nodes on it's LAN interfaces. 

I don't like that idea.  

If I type "host www.foo.com" on my end system, I want to see what DNS has 
to offer, not what $somerandomdevice in the DNS recursion path thinks I 
might want to see.

If there is no IPv6 on the WAN side, and the client still does IPv6, send
back proper ICMP unreachables - and if the client cannot handle that, fix the
client.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 13:56:36 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Joel Jaeggli
Sent: Monday, March 14, 2011 3:11 PM
To: james woodyatt
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

Joel,

>managing the interior network as well.

I agree most cpe routers have a bridge internal to the device between
the WAN and the LAN of the device.  However, when one is considering any
LAN interface on the cpe, I don't see any use for the LAN interface to
be a bridge.  My general comment is that the cpe is an IPv6 router, so
the least the device has got to support is an IGP in the LAN.  Thus I
agree that an IGP such as RIPng should be a MUST for support in the LAN
of the cpe.  If the IETF cannot get an agreement on this issue, I guess
it's fine.  Some cpe router vendors will implement RIPng or other IPv6
IGPs and when we have interop issues we will come back to the IETF
because if it's anything that the IETF is great with is to sort out
Interop issues between different vendor implementations.  That is why it
is best if the IETF does mandate at least one IGP for a MUST.  The power
grid folks already came to the Beijing IETF showing us their cpe router
devices will force the home to be multihomed.  Power grid aside, there
are finite number of homes that are multihomed already.  Thus multihomed
is one use case that will use the IGP in the home to distribute routes
between different routed domains. 

If one wants the IGP in the LAN to be a MAY, please articulate why and
please explain how you will solve distributing routes between routed
domains in the multihomed home.

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 20:19:27 +0100 (CET)

> domains in the multihomed home.

If DHCPv6-PD is used in the home and only the cpe router is advertising 
itself as a router using RA in the LAN, then it can be the default gateway 
for the LAN and do forwarding between the devices that have aquired 
prefixes using PD from it.

Yes, routing will not be optimal but it'll work, and using ICMP redirects 
traffic will actually not be suboptimal for long.

Doesn't this work for multihoming as well, we can have multiple prefixes 
on the same LAN and the Customer Interior Router can get multiple PDs from 
the different spaces?

Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no 
mention of multihoming, would this be done with two connections to one 
device, or two devices?

Also, if IGP support is only needed in the multihoming scenario, do we 
really need to make it a MUST/SHOULD for all devices this draft is 
handling? Can't it be a multihoming MUST then?

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:34:06 +1300

On Wed, Mar 16, 2011 at 7:56 AM, Hemant Singh (shemant)
<[email-masked]> wrote:
...
> be a bridge.

Huh? On small CPEs in my experience, the LAN side *always* behaves as a switch
(i.e. a multiport bridge). That is a very useful property. They bridge between
802.3 and 802.11, too.

Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs stop
doing it, the better.

> My general comment is that the cpe is an IPv6 router, so
> of the cpe.

As I said earlier, I think a MAY is sufficient - the vendors will decide anyway.
I would accept a SHOULD for RIPng too. But if someone sees a market for
a cheap CPE that supports exactly one flat /64 subnet, who are we to tell
them not to sell that?

      Brian

> If the IETF cannot get an agreement on this issue, I guess

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 20:41:38 +0100 (CET)

On Wed, 16 Mar 2011, Brian Carpenter wrote:

> Bridging the LAN and WAN sides is a heresy, of course, and the sooner 
> CPEs stop doing it, the better.

I don't see any reason for such a device to be handled in this draft, 
anyway. It's a cpe *router* draft, if it does L2 bridging between LAN and 
WAN then it's not a router, it's a media converter or a switch.

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:44:25 +1300

On Wed, Mar 16, 2011 at 8:19 AM, Mikael Abrahamsson <[email-masked]> wrote:

...
> Doesn't this work for multihoming as well, we can have multiple prefixes on
> the same LAN and the Customer Interior Router can get multiple PDs from the
> different spaces?
>

It's stating the obvious that a router MUST support multiple
simultaneous prefixes;
see the many references to "delegated prefix(es)" in
draft-ietf-v6ops-ipv6-cpe-router.

Is it the business of this spec to state whether the CPE has more than one WAN
interface?

     Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 14:47:02 -0500

-----Original Message-----
From: Brian Carpenter [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 3:34 PM
To: Hemant Singh (shemant)
Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG
Subject: Re: [v6ops] I-D

>(i.e. a multiport bridge). That is a very useful property. They bridge
between

The "internal" does include specific hardware that bridges not just
between the WAN and the LAN but as you said, any LAN interface, if
necessary.  This is the property of the bridged hardware. 

>Bridging the LAN and WAN sides is a heresy, of course, and the sooner
CPEs stop
>doing it, the better.

Not heresy.  Any networking router hardware can be programmed to be a
network switch or a network bridge.  

Hemant

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:50:44 +1300

On Wed, Mar 16, 2011 at 8:41 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs
>> stop doing it, the better.
>

And will not work properly for IPv6, which intrinsically requires a
router. I think
this should be stated somehow, in a few words.

     Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 20:51:24 +0100 (CET)

> draft-ietf-v6ops-ipv6-cpe-router.

Oki, I looked at the network drawing and there was only a single SP and 
there was only a single uplink router. If there is a scenario with 
multiple devices from multiple SPs that is to be included in this draft, 
then I think the scenario needs to be explained.

> Is it the business of this spec to state whether the CPE has more than one WAN

I don't know. If the IGP requirement for multihoming is because there are 
multiple SPs and multiple CPE routers in the home (one from each SP), 
doesn't that need to be explicitly stated?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 14:59:11 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 3:19 PM
To: Hemant Singh (shemant)
Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG
Subject: Re: [v6ops] I-D

>on the same LAN and the Customer Interior Router can get multiple PDs
from 

How does my home computer addressed with the SP1 IPv6 global address
from PD1 print to the printer addresses with the SP2 IPv6 global address
from PD2 unless the PD2 subnet prefix is propagated by some means
between the two network domains?  An IGP is needed or one could use MSR
(RFC 4191) in some cases of the home network. 

>mention of multihoming, would this be done with two connections to one 

You are correct.  The current version does not support multihoming.
However multihoming is one feature that is under consideration to add to
the document.  One use case we have in mind is a home served by two
different SP's using two different IPv6 CE routers with one WAN
interface on each device. 

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 21:05:46 +0100 (CET)

> (RFC 4191) in some cases of the home network.

In this scenario an IGP is indeed needed.

So for a device to support this setup, IGP is a MUST. I do though see a 
lot of trouble to get this kind of setup to work automatically, how do you 
get DNS to work for instance?

> interface on each device.

In that case, make this a specific deployment scenario and make an IGP a 
MUST, in the other cases it can be a CAN.

How do we choose the IGP? From what I know, RIP (any variant) seems more 
prevalent than OSPF on this class of devices historically, should that be 
interpreted as RIP being easier to implement and that's why it should be 
preferred over OSPF for home use?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 15:13:16 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 4:06 PM
To: Hemant Singh (shemant)
Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>get DNS to work for instance?

How does DNS work today in an Enterprise across two routed domains with
different subnet prefixes?  One way is to have both domains go to one
root DNS server for the domains.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 21:20:59 +0100 (CET)

On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote:

>> lot of trouble to get this kind of setup to work automatically, how do 
>> you get DNS to work for instance?
>

I guess I wasn't clear. Let me try to be more specific:

How would the printer automatically be discovered in the home, or at least 
how would a DNS name pointing AAAA to the printers IPv6 address be entered 
into a domain name the user can enter, that would dynamically change as 
the PD prefixes change over time?

---

From: [email-masked]
Date: Tue, 15 Mar 2011 21:28:14 +0100 (CET)

> this should be stated somehow, in a few words.

I don't see *why* IPv6 wouldn't work for instance behind a plain bridge
type DSL modem. But if that is indeed the case, it needs to be explained.

Agreed that such a device is not relevant for a CPE router document.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Mar 2011 21:29:52 +0100

Mikael,

>>> So for a device to support this setup, IGP is a MUST. I do though see a lot of trouble to get this kind of setup to work automatically, how do you get DNS to work for instance?
>> 
> How would the printer automatically be discovered in the home, or at least how would a DNS name pointing AAAA to the printers IPv6 address be entered into a domain name the user can enter, that would dynamically change as the PD prefixes change over time?

Service Discovery has to be extended to work across a larger scope than link-local.
i.e. you also need automatically enabled multicast routing in these networks too.
see the failed homenet charter.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 13:38:22 -0700

On Mar 15, 2011, at 11:56 , Hemant Singh (shemant) wrote:
> 
> The power grid folks already came to the Beijing IETF showing us their cpe router devices will force the home to be multihomed.

Huh?  Where is the draft that documents this?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 15:38:54 -0500

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, March 15, 2011 4:30 PM
To: Mikael Abrahamsson
Cc: Hemant Singh (shemant); IPv6 Ops WG
Subject: Re: [v6ops] I-D

>see the failed homenet charter.

Thanks, Ole. Also, Mikael, if one uses the ULA addressing on the CE
router and the printer, then the ULA is constant and easier for DNS to
manage.  Even when the SP link goes down and thus the global on the
nodes is no longer usable, the ULA persists.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 15:47:55 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Tuesday, March 15, 2011 4:38 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>Huh?  Where is the draft that documents this?

http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00

Snipped from the Abstract of the document above, is this text between
squared brackets.

[WiFi access points, cable boxes and other home devices with internet
access could all be internetworked with smart metering devices by
customers with no data networking expertise resulting in a complex
multi-segment network with differing prefixes, routing support and
service discovery needs.]

I am sure there is other text in the document that points out two
different routers in the home connected to two different SPs (one SP is
the home's DSL or broadband SP and the other SP is the Power Grid
company with their IPv6 CE router for the home) and thus one has a
multihomed home.  Anyway, you should look at Tom Herbst's prezo given to
the v6ops at the IETF79 in Beijing that clearly shows a multihomed
network.  Note also that multihomed involves both a multihomed WAN and
LAN for CE Router.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 21:48:55 +0100 (CET)

> nodes is no longer usable, the ULA persists.

So the recommendation is that all home subnetworks should have ULA as well 
as one PD prefix from each SP? Is the ULA prefix PDed from the CPE router 
so all home routers gets multiple PDs?

Or is this where the IGP comes in, that each router in the home should 
create a ULA for each LAN interface and announce this to its upstream 
interface (not to the SP, but to the CPE router) ?

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Mar 2011 07:24:58 +1030

Hi Gert,

On Tue, 15 Mar 2011 12:41:19 +0100

> to offer, not what $somerandomdevice in the DNS recursion path thinks I 

It could be an option to switch this behaviour off in a CPE for people
such as yourself.

dnssec would probably stop this working, so that probably limits its
usefulness lifetime.

> back proper ICMP unreachables - and if the client cannot handle that, fix the

I certainly think this is a better solution. However there are a few
things that may influence is effectiveness - that generating
unreachables is a SHOULD not a MUST, and they're rate limited, so
there are still opportunities for the IPv6 unreachable timeouts.

Regards,
Mark.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 13:55:50 -0700

Hi Hermant,

Both Tom Herbst and myself (Don Sturek, representing Pacific Gas and
Electric) will be in Prague and would like to discuss further the CPE
Enhancements draft and the requirements around internetworked CPE within a
home.

As outlined in the
http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 draft,
activities are underway to deploy IPv6 enabled smart meters as well as
support in WiFi and HomePlug to internetwork these smart meters with
existing home networks connected to existing ISPs.

The scenarios described in the draft are a little more than a year from
large scale deployment (11 million smart meters installed to date)

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Tuesday, March 15, 2011 1:48 PM
To: james woodyatt; IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

-----Original Message-----

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 15:58:13 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 4:49 PM
To: Hemant Singh (shemant)
Cc: Ole Troan; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>so all home routers gets multiple PDs?

IPv6 from the womb supports multiple IPv6 addresses configured on a
network interfaces.  Yes, the hosts in the home are expected be served
by multiple PD's - at least the ULA and one global IPv6 PD from the SP. 

>interface (not to the SP, but to the CPE router) ?

Yes.  However, if the routed topology of the home in a tree topology and
the routers are thus using recursive prefix delegation, then no IGP is
needed to propagate a downstream PD subnet prefix to the upstream
router(s).  The reason is because the upstream router snoops dhcpv6
messages during prefix delegation and thus the router knows what prefix
subnet is assigned downstream.  Soon as the home network is NOT a tree
routed topology, an IGP is needed to propagate subnet prefix routes
upstream. 

Hemant

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 15 Mar 2011 14:00:31 -0700

Multihoming is not the primary requirement for an IGP from the herbst
draft, though, it is different framing typed mac/phy's.

The requirement for a IGP is that there is a need for intra-home routing
between 802.3 framed networks and 802.15.4 in-home networks.

There are two likely scenarios -
 1) God box - Internet 802.3 (WAN) connection, 802.11 interior connection,
802.3 interior connection(s) and a 802.15.4 connection

Or 

2) multiple boxes - one from retail or SP with Internet 802.3 (WAN)
connection, 802.11 interior connection, 802.3 interior connection(s)
And a second with 802.3 and 802.15.4

With number 2, to enable Internet connectivity to the 802.15.4 network and
general connectivity between the 802.11/802.3 networks and the 802.15.4
network, an IGP is required.

tom

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 16:01:01 -0500

Don,

Good to hear from you.  I am also attending the IETF in Prague. I'd be
happy to sit down with you guys again (like we did in Beijing) and work
out the issues. 

Hemant

-----Original Message-----
From: Don Sturek [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 4:56 PM
To: Hemant Singh (shemant); 'james woodyatt'; 'IPv6 Ops WG'
Subject: RE: [v6ops] I-D

Hi Hermant,

Both Tom Herbst and myself (Don Sturek, representing Pacific Gas and
Electric) will be in Prague and would like to discuss further the CPE
Enhancements draft and the requirements around internetworked CPE within
a
home.

As outlined in the

Don

-----Original Message-----
Of

-----Original Message-----

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 22:08:32 +0100 (CET)

> routed topology, an IGP is needed to propagate subnet prefix routes

How does the CE router know what ULA the home IR has on it's LAN 
interface?

Or is the intention do to PD both for the SP prefix and the ULA prefix 
from the CE, so any home IR always ask for multiple prefixes using PD, or 
can the CE PD multiple prefixes at once and the proposed design is that it 
should?

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 14:20:19 -0700

Hi Hemant,

Yes, let's find some time for sure.  We have a draft proposal to discuss
with Stuart Cheshire on extending m-DNS for site local multicasts
(http://datatracker.ietf.org/doc/draft-lynn-dnsext-site-mdns/) plus we are
working on a white paper covering the following topics (note the white paper
is for discussion and portions may make sense for incorporation into the
advanced CPE requirements draft):

1)    White paper to address allocation of ULA prefixes, ULA address
autoconfiguration and DAD, rules on limiting propagation of ULA prefixes
beyond residence boundaries
      a. Define location where the ULA prefix is generated (default values
if we can agree to them also)
      b. Define mechanism to distribute ULA prefixes
      c. Define mechanism to create unique ULA addresses from prefix (or
more likely point to other drafts which do this like Autoconf)
      d. Define mechanism to stop propagation of ULA prefixes (which is
probably the start of a much more complex problem)
      e. Propose either delegation (and realignment/DAD of updated ULA
addresses) or a proxy and proxy agent to interconnect different ULA domains
in a residence

3)      White paper to define how an LBR (6LoWPAN border router) gets it
global prefix to use (from the prefix space of the subscriber network).    
      a.   Probably use DHCP on the LBR to allocate the prefix from the
subscriber network.

As soon as our schedule is known, I will drop you a note and see if we can
get together for 1-2 hours to discuss.

Don

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 2:01 PM
To: [email-masked]; james woodyatt; IPv6 Ops WG
Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

Don,

Hemant

-----Original Message-----
From: Don Sturek [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 4:56 PM
To: Hemant Singh (shemant); 'james woodyatt'; 'IPv6 Ops WG'
Subject: RE: [v6ops] I-D

Hi Hermant,

As outlined in the

Don

-----Original Message-----

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Mar 2011 22:40:35 +0100 (CET)

> routed topology, an IGP is needed to propagate subnet prefix routes 

Btw, since users will have to send out traffic to the respective SP only 
from the prefixes that SP has delegated, I guess we not only need an IGP, 
but some kind of policy routing (source based) so that packets going from 
hosts to the Internet end up on the correct SP?

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 15 Mar 2011 22:53:38 +0100

> network, an IGP is required.

I don't see that - as long as the 802.15.4 device acts as a router,
requesting required IP space for the 802.15.4 domain via DHCPv6-PD from
the home internet gateway router.

Why is a full-blown dynamic IGP needed? How does the 802.15.4 gateway
discover what address range it could advertise in IGP for own use?

Do we really want IGP-enabled residential home LANs, where every device
plugged in to can advertise arbitrary routes?

As a home network "operator" and SP I seriously frown upon this
scenario having random smart meter devices inject random routing
information into my home network.

What exactly is the scenario which requires non-hierarchical controlled
routing that a DHCPv6-PD cascade would be able to provide?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 14:54:26 -0700

Hi George,

We also meant to address the propagation of site local multicasts beyond
residence boundaries as well.  That said, I will be sure to attend your
presentation as we don't really care how the problem is addressed (so long
as our site local multicasts don't end up outside the residence!).......

Don

-----Original Message-----
From: George Michaelson [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 2:33 PM
To: [email-masked]
Cc: Hemant Singh (shemant); james woodyatt; IPv6 Ops WG; Simpson, Robby (GE
Energy Services); Geoff Huston
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

> probably the start of a much more complex problem)

As a point of information on this Don, Have a look at:

http://tools.ietf.org/html/draft-michaelson-as112-ipv6-00

Which I will be presenting on in Prague/DNSOPS I hope.

A *significant* daily volume of reverse-DNS is seen into ULA space. It far
outweighs global unicast IPv6 requests on the ip6.arpa service. The query
sources are widespread. This strongly suggests that a ULA deployment is out
there in the wild, causing some kind of service to request 'who is that'
into un-delegated reverse space.

I understand you meant routing propagation, but I thought I'd point out
there are other kinds of information leak about 'local' addresses

Oh, and the multicast ranges are in there too. Link and Site scoped
boundaries, the works.

-George=

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 11:07:52 +1300

On 2011-03-16 09:20, Mikael Abrahamsson wrote:
>>> So for a device to support this setup, IGP is a MUST. I do though see
>>> a lot of trouble to get this kind of setup to work automatically, how
>>> do you get DNS to work for instance?
>>
> How would the printer automatically be discovered in the home, or at
> least how would a DNS name pointing AAAA to the printers IPv6 address be
> entered into a domain name the user can enter, that would dynamically
> change as the PD prefixes change over time?

Isn't that exactly what dynamic DNS update is for?

As I said, we need to decide whether real DNS + dynamic update is
recommended, or mDNS.

If not, you do indeed need routed multicast for discovery. Do we really
want to go there?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 11:10:27 +1300

> type DSL modem. But if that is indeed the case, it needs to be explained.

If you get a /56 you really need to be a router, surely.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 11:11:51 +1300

> interface on each device. 

Why does that change the requirements for an IPv6 router? It's 100%
standard IPv6 deployment.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 15:26:17 -0700

On Mar 15, 2011, at 13:47 , Hemant Singh (shemant) wrote:
> [I boggled at the claim:]

I read that draft when it was first published.  It documents no such thing.

> network.  Note also that multihomed involves both a multihomed WAN and

There is no language in the draft respecting site-multihoming of residential networks.  There is the somewhat ambiguous section 2.3 "Intra-network routing with multiple internet connected CPEs" which says this:

   As network segments are interconnected, and CPE devices become border
   gateways for new bordering network segments, a routing protocol like
   RIPng needs to be supported.  As noted for ULA delegation, the CPE
   needs to automatically detect the need in support for inter-segment
   routing and provide support automatically.

Admittedly, this could be interpreted to mean multi-homing at residential sites.  Maybe there was a presentation slide set in Beijing that explained clearly what this section is supposed to mean, but if so then I missed it.  Was there such a presentation?

My abiding and overarching question, which I have been asking for more than a year now without satisfactory answer, remains unanswered: what is forcing this to happen, and why are other obvious alternatives unsatisfactory?

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 15:36:03 -0700

> network, an IGP is required.

Would somebody please explain in clear technical detail why the obvious alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an unsatisfactory solution to the problem of not being able to bridge between 802.1D and 802.15.4?

A related question is why an application proxy, which has the virtue of working when the residential Internet service provider is IPv4-only, is also an unsatisfactory solution to the Internet connectivity problems of the 802.15.4 engineering community?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Mar 2011 17:37:30 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 5:09 PM
To: Hemant Singh (shemant)
Cc: Ole Troan; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>How does the CE router know what ULA the home IR has on it's LAN 

When the CE router is powered up the CE router will generate a ULA
prefix.  Thereafter an internal DHCPv6 server inside the CPE router
delegates the ULA prefix to the LAN interfaces.

>can the CE PD multiple prefixes at once and the proposed design is that
it 

The Basic IPv6 CE router document that covers the topic of ULA does not
go into such details and does not need to.  The PD acquisition can
happen in any order for the ULA or the GUA (Globally Unique Address).  

Hemant

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 15:51:29 -0700

Hi James,

>From your question below, could you provide a bulletized list of what an
"application proxy" between an IEEE 802.15.4 subnet and a residential ISP
subnet would do?  Here are my questions:
1)  You mentioned ND-proxy already
2)  DNS proxy?
3)  DAD?
4)  ULA prefix proxy?
5)  Multicast propagation (or is this assumed to be not supported for site
locals since you assumed DNS proxy?)
6)  Other services
Just trying to understand what all this proxy would be doing........

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, March 15, 2011 3:36 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

> network, an IGP is required.

Would somebody please explain in clear technical detail why the obvious
alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an
unsatisfactory solution to the problem of not being able to bridge between
802.1D and 802.15.4?

A related question is why an application proxy, which has the virtue of
working when the residential Internet service provider is IPv4-only, is also
an unsatisfactory solution to the Internet connectivity problems of the
802.15.4 engineering community?

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 17:18:27 -0700

> Just trying to understand what all this proxy would be doing........

You have some smart meter device on your 802.15.4 network.  There are two ways an application proxy can help solve your connectivity problem.

+ To make the smart meter device reachable from the IPv6 Internet: via service through an application proxy running on a host on the 802.1D network with another interface to the 802.15.4 network.  It would make any registrations in service directories required by the smart meter on its behalf.  It would receive connections from remote peers and forward them in application layer to the real smart meter devices on the 802.15.4 network.

+ To make services on the IPv6 public Internet reachable from the smart meter device: via an application proxy running on a host on the 802.15.4 network with another interface to the 802.1D network where a global IPv6 prefix is advertised.  It would advertise a ULA prefix to the 802.15.4 network and no global prefix.  It would answer service directory queries from smart meter devices with its own ULA address and proxy the remote Internet services to hosts on the 802.15.4 network.  Remote servers at IPv4 addresses would be proxied over the application layer on IPv6.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 17:31:41 -0700

Hi James,

I don't see how the suggestions below would work in an environment where the
customer can bring in new devices, associate them to the network and expect
access to their smart meter from WiFi, HomePlug or other medium not directly
attached to the smart meter (but internetworked through CPE).  Wouldn't your
suggestion entail a lot of configuration if any new home network interface
is introduced?

I think we should focus on solving the problems in the home without having
to configure an application gateway for every new interface.

Don

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 5:18 PM
To: [email-masked]
Cc: 'IPv6 Ops WG'
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

> Just trying to understand what all this proxy would be doing........

You have some smart meter device on your 802.15.4 network.  There are two
ways an application proxy can help solve your connectivity problem.

+ To make the smart meter device reachable from the IPv6 Internet: via
service through an application proxy running on a host on the 802.1D network
with another interface to the 802.15.4 network.  It would make any
registrations in service directories required by the smart meter on its
behalf.  It would receive connections from remote peers and forward them in
application layer to the real smart meter devices on the 802.15.4 network.

+ To make services on the IPv6 public Internet reachable from the smart
meter device: via an application proxy running on a host on the 802.15.4
network with another interface to the 802.1D network where a global IPv6
prefix is advertised.  It would advertise a ULA prefix to the 802.15.4
network and no global prefix.  It would answer service directory queries
from smart meter devices with its own ULA address and proxy the remote
Internet services to hosts on the 802.15.4 network.  Remote servers at IPv4
addresses would be proxied over the application layer on IPv6.

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 17:32:43 -0700

On Mar 15, 2011, at 5:18 PM, Thomas Herbst wrote:
> 
> Does every 802.15.4 application level gateway now need to be upgraded for the "lightbulb app"?

I don't know.  Presumably, someone with deeper knowledge of applications for 802.15.4 networking can speak authoritatively about what requirements might arise for application proxies in this scenario.

Is there anyone with enough authority here to tell us?

> The problem we are trying to solve is to connect subnets of different mac/phys together.  The way to do that is to layer 3 forwarding.

Maybe if I recite the link to RFC 4389, I'll get some traction:

  <http://tools.ietf.org/html/rfc4389>

Just to be really thorough, I'll quote the abstract too.

   Bridging multiple links into a single entity has several operational
   advantages.  A single subnet prefix is sufficient to support multiple
   physical links.  There is no need to allocate subnet numbers to the
   different networks, simplifying management.  Bridging some types of
   media requires network-layer support, however.  This document
   describes these cases and specifies the IP-layer support that enables
   bridging under these circumstances.

Seriously, why doesn't neighbor discovery proxy offer the optimal solution here?  I understand that layer-3 forwarding can be made to solve this problem.  What I don't understand is why we are discounting the operational advantages of neighbor discovery proxy.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 17:42:26 -0700

Hi James,

Sure, I am the chair for the core stack team responsible for the networking
portion.  My comments below marked with DON....

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, March 15, 2011 5:33 PM
To: Thomas Herbst
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

> Does every 802.15.4 application level gateway now need to be upgraded for
the "lightbulb app"?

I don't know.  Presumably, someone with deeper knowledge of applications for
802.15.4 networking can speak authoritatively about what requirements might
arise for application proxies in this scenario.

DON:  If everytime anyone adds a new application we require an application
proxy then your suggestion does not scale and won't work.   That would be a
shame for a current install base of 11 million devices we plan to switch
onto IPv6 next year.

> The problem we are trying to solve is to connect subnets of different
mac/phys together.  The way to do that is to layer 3 forwarding.

Seriously, why doesn't neighbor discovery proxy offer the optimal solution
here?  I understand that layer-3 forwarding can be made to solve this
problem.  What I don't understand is why we are discounting the operational
advantages of neighbor discovery proxy.

DON:  So who configures the neighbor discovery proxy when a customer brings
a new CPE home from the store?  If this is somehow expected to happen
automatically, I would rather solve the ULA and inter-residence routing
problem than try to figure out how to configure an application proxy like
you are suggesting.

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 15 Mar 2011 17:18:42 -0700

James, 

I can't say those solutions won't work.  There are lots of ways to build a
system.

The applications we are developing on the 802.15.4 networks are IP based
applications.  We are doing that because we'd like to have the benefits of
IP networking.  While there are utility applications on the 802.15.4
network, it is the user's network and we should provide IP connectivity
such that they can run what they want on it.

I recently saw a startup demonstrate an IP networking enabled lightbulb.
It is 802.15.4, but does not run the same applications we are putting on
the utility meters. Does every 802.15.4 application level gateway now need
to be upgraded for the "lightbulb app"?

The problem we are trying to solve is to connect subnets of different
mac/phys together.  The way to do that is to layer 3 forwarding.
An IGP (I don't care which one) is the obvious way to enable customers to
interconnect their networks in arbitrary fashion, rather than hacking on a
ND-proxy.

One other problem mentioned on this thread was the issue of routes sent
back to the provider.
First, routing updates should not be sent to the provider, second, the
provider should not be listening to routing updates from CPE.

tom

On 3/15/11 3:36 PM, "james woodyatt" <[email-masked]> wrote:

>alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is
>an unsatisfactory solution to the problem of not being able to bridge
>between 802.1D and 802.15.4?
>
>working when the residential Internet service provider is IPv4-only, is
>also an unsatisfactory solution to the Internet connectivity problems of
>the 802.15.4 engineering community?
>
>
>--

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 18:29:36 -0700

> problem than try to figure out how to configure an application proxy like

I don't see how this problem can be any more complicated than configuring the router you plan to use as the border between the 802.1D and 802.15.4 segments behind a CPE gateway.  It *should* be substantially less complicated.  You tell the ND-proxy what 802.11 SSID to join or you plug a CAT-5 cable into its RJ-45 jack, then you tell it whatever parameters it needs to be a part of the 802.15.4 networks it will be bridging.  You're done.

Both 802.15.4 and 802.11 have simplified protected network setup methods, i.e. WPS in the case of 802.11 and I'm sure there's gotta be something like Bluetooth pairing for 802.15.4, right?  Plugging CAT-5 into RJ-45 jacks is *really* easy.

I feel certain that even nearly-fossilized electric utility companies can find technical writers who can handle the cognitive burden all this will place on ordinary consumers who buy cheap gear from their local $0.99 hardware stores.  I'm extremely dubious, however, about that cognitive burden being manageable when the bastion between 802.15.4 and 802.1D is a router, which by the way has all the same configuration problems as a ND proxy box plus the fact that you have to configure... well, a *router*.  Have you tried configuring one of those?  I'm told there are companies that, for a nominal fee, will *certify* you as a competent technician skilled in configuring them.  Some people make a living configuring and maintaining other people's routers.

Hmmm. Maybe, just maybe, that's the whole point of this exercise?  Nah, that couldn't be it.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 15 Mar 2011 19:16:10 -0700

Hi James,

You should get off of your soap box and get into the real world.

Maybe we should find actual engineers in the v6ops group to look into the
issue rather than folks interested in looking after their legacy deployments
that actually don't work.

Don

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 6:30 PM
To: [email-masked]
Cc: 'Thomas Herbst'; 'IPv6 Ops WG'
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

> problem than try to figure out how to configure an application proxy like

I don't see how this problem can be any more complicated than configuring
the router you plan to use as the border between the 802.1D and 802.15.4
segments behind a CPE gateway.  It *should* be substantially less
complicated.  You tell the ND-proxy what 802.11 SSID to join or you plug a
CAT-5 cable into its RJ-45 jack, then you tell it whatever parameters it
needs to be a part of the 802.15.4 networks it will be bridging.  You're
done.

Both 802.15.4 and 802.11 have simplified protected network setup methods,
i.e. WPS in the case of 802.11 and I'm sure there's gotta be something like
Bluetooth pairing for 802.15.4, right?  Plugging CAT-5 into RJ-45 jacks is
*really* easy.

I feel certain that even nearly-fossilized electric utility companies can
find technical writers who can handle the cognitive burden all this will
place on ordinary consumers who buy cheap gear from their local $0.99
hardware stores.  I'm extremely dubious, however, about that cognitive
burden being manageable when the bastion between 802.15.4 and 802.1D is a
router, which by the way has all the same configuration problems as a ND
proxy box plus the fact that you have to configure... well, a *router*.
Have you tried configuring one of those?  I'm told there are companies that,
for a nominal fee, will *certify* you as a competent technician skilled in
configuring them.  Some people make a living configuring and maintaining
other people's routers.

Hmmm. Maybe, just maybe, that's the whole point of this exercise?  Nah, that
couldn't be it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Mar 2011 06:01:29 +0100 (CET)

> happen in any order for the ULA or the GUA (Globally Unique Address).

I wasn't talking about the basic document, I was talking about the new 
one.

Does the home IR aquire ULA *and* GUA using DHCPv6-PD from the CE, or does 
it create an ULA itself? How does the home IR what role it has, I would 
imagine it would be an identical device as the CE, so if this is to be 
plug and play, it needs to auto-discover this?

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Mar 2011 19:15:18 +1030

Hi James,

On Tue, 15 Mar 2011 17:32:43 -0700
james woodyatt <[email-masked]> wrote:

> Seriously, why doesn't neighbor discovery proxy offer the optimal solution here?

ULAs only for 802.16.4 devices, global + ULAs for other
devices in the home. Possibility of multicast video, which would likely
flatten the 802.16.4 devices' batteries in minutes if not seconds,
and would have somewhat similar impacts on wifi connected laptop
batteries. Segregation of networks for different security / Internet
access policies and/or audit e.g. parent net verses children net.

>  I understand that layer-3 forwarding can be made to solve this
>  problem.  What I don't understand is why we are discounting the
>  operational advantages of neighbor discovery proxy.
> 

I think subnets provide a convenient tool to group devices together
when they have common attributes or requirements - they're not
necessarily useful just to overcome different link layer framing
formats. If we can't use subnets to group devices together, then any
decisions to perform actions based on these attributes or requirements
needs to based on individual devices identities. For example, you could
avoid the negative impacts of e.g. multicast video on a bridged or ND
proxied segment of mixed 802.3 and 802.16.4 devices by moving to an
NBMA/NHRP model for the segment. Unfortunately you'd lose the
efficiency of link layer multicasts when you gain the ability to be
more selective about what types of traffic is sent to specific
end-nodes.

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Mar 2011 20:38:04 -0500

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 6:12 PM
To: Hemant Singh (shemant)
Cc: Mikael Abrahamsson; IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>standard IPv6 deployment.

Agreed.  However the design team is stepping gingerly.   We first did a single IPv6 CE router in the home case which is the Basic IPv6 CE Router document in the RFC Editor Queue.  The bis document covers a specific two-router case.   It's only the fact that making all IPv6 features of the CE Router work with multihoming is the issue.  For some features solutions don't even exist.  So what does a document like ours propose for solution to use? 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Mar 2011 20:48:30 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Tuesday, March 15, 2011 6:36 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>Would somebody please explain in clear technical detail why the obvious
alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4,
is an unsatisfactory solution to the problem of not being >able to
bridge between 802.1D and 802.15.4?

Indeed when one has two disparate transports with different MAC layers,
one cannot bridge data between the two transports.  Thus ND Proxy is one
alternative that jumps to mind.  See this text in the bis document.

[LNDP-1:  If the CE Router has only one /64 prefix to be used across
multiple LAN interfaces and the CE Router supports any two LAN
interfaces that cannot bridge data between them because the two
interfaces have disparate MAC layers, then the CE Router MUST support
Proxying Neighbor Advertisements as specified in Section 7.2.8 of
[RFC4861].] 

However the bis document adds ND Proxy for only once specific case for
legacy 3GPP networks where the operator could dole out only one /64 to
the CE router.  If a shorter than /64 prefix is assigned to the CE
Router, one should use routing between the two transport layers.

Hemant

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Mar 2011 19:03:29 -0700

> bridge between 802.1D and 802.15.4?

Because you can't take a packet off an 802.3 LAN and drop it on an 802.15.4 LAN...

Compare http://en.wikipedia.org/wiki/Ethernet_frame#Structure with age 45 of http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf

And besides, 1518 octets doesn't fit very well in 127.

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Mar 2011 20:01:39 -0700

Why don't all of these argument apply equally to both ND-proxy forwarding and layer-3 forwarding? I see no technical distinction.

In both cases, you have to strip the sub-IP header to forward across interfaces. In both cases you have link-MTU trouble to manage.

--jhw (sent from my phone)

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Mar 2011 21:56:18 -0700

That is a great analysis if you're routing.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Mar 2011 09:01:26 -0500

-----Original Message-----

ND Proxy has one pitfall that routing does not.  When ND Proxy proxies a
ND control packet such as a multicast NS from one segment to another,
the packet will be multicast to the other segment and thus a multicast
flood occurs.  In contrast, when the two segments are routed, each
segment is a separate ND link-local domain and no flooding of multicast
occurs from one segment to another.  Note also, one recommends ND Proxy
strictly for the case when one has one subnet prefix to use across two
network segments.  For Tom's use case, we have each of the two routers
using ULA and/or GUA that are shorter than /64, and thus routing is a
better solution.  

Hemant

---

From: George Michaelson <[email-masked]>
Date: Tue, 15 Mar 2011 14:32:48 -0700

A *significant* daily volume of reverse-DNS is seen into ULA space. It far outweighs global unicast IPv6 requests on the ip6.arpa service. The query sources are widespread. This strongly suggests that a ULA deployment is out there in the wild, causing some kind of service to request 'who is that' into un-delegated reverse space.

I understand you meant routing propagation, but I thought I'd point out there are other kinds of information leak about 'local' addresses

Oh, and the multicast ranges are in there too. Link and Site scoped boundaries, the works.

-George

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Mar 2011 09:27:12 -0700

> using ULA and/or GUA that are shorter than /64, and thus routing is a

You seriously mean to trade the additional operational complexity of provisioning, configuring and administering a routed home internet to save the cost of multicasting ICMPv6 messages?

This does not sound like a sensible trade to me.

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Mar 2011 17:31:49 +0100

James,

> You seriously mean to trade the additional operational complexity of provisioning, configuring and administering a routed home internet to save the cost of multicasting ICMPv6 messages?

is there anything implied by routing that requires operational complexity?
there are multiple proposals for zero configuration routing. as far as I see there is no reason why we couldn't design a self configuring network at layer 3.

> This does not sound like a sensible trade to me.

ND proxies fail as soon as you have a loop in the network.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Mar 2011 10:11:12 -0700

> there are multiple proposals for zero configuration routing. as far as I see there is no reason why we couldn't design a self configuring network at layer 3.

RIPng is not zero-configuration.  Neither is OSPF.  Searching the Internet draft archives, I find this abandoned draft from over ten years ago, which is an example of the sort of proposal I'm expecting to see:

  <http://tools.ietf.org/html/draft-akinlar-zeroconf-zrip>

That draft was Informational and never updated.  I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series.  If there are "multiple" proposals for zero-configuration residential network routing protocols, then I'd like to see them now, please.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 17 Mar 2011 11:03:17 -0700

On 3/17/11 10:11 AM, james woodyatt wrote:

> That draft was Informational and never updated.  I can't find any
> other references to zero-configuration routing anywhere in the
> Internet draft archives or the RFC series.  If there are "multiple"
> proposals for zero-configuration residential network routing
> protocols, then I'd like to see them now, please.

We've got practical demonstrations of real-world use of residential
devices running routing protocols in ipv4, to the they're far from
universal.

It doesn't take much, or indeed a new protocol to make say ripng work in
a resdential enviroment, just some generic assumptions of the parameters
that a ripng speaker would use. I don't see the outcome as more dire
than honoring router advertisements or dhcpv6 responses.

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Mar 2011 19:02:32 +0100

James,

> RIPng is not zero-configuration.  Neither is OSPF.  Searching the Internet draft archives, I find this abandoned draft from over ten years ago, which is an example of the sort of proposal I'm expec…

what do you expect needs to be configured in RIP?
apart from the router-id, in OSPF?

what is your plan to handle loops in your ND proxies network? there is a reason that is experimental after all.

> That draft was Informational and never updated.  I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series.  If there are "multiple"…

http://datatracker.ietf.org/doc/search/?name=zerouter&rfcs=on&activeDrafts=on&oldDrafts=on
http://datatracker.ietf.org/doc/draft-dimitri-zospf/

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Mar 2011 13:18:22 -0500

James,

I and Ole provided clear technical reasons for using routing over ND
Proxy for Tom's use case of the HAN network internetworking with the
home network.  Then you said routing is not automatically or easily
configurable.  Here is an example of RIPng I configured on my Cisco IPv6
ubr10000 router.  The network interface of GigabitEthernet4/0/0 on my
IPv6 router is already up and running with an IPv6 global address
configured.  This is all I have to do on the router to configure RIPng
and then have the GigabitEthernet4/0/0 join the RIPng network.  As you
can see, the configuration below is totally automatable. 

shark(config)#ipv6 router rip labripng
shark(config-rtr)#redistribute connected 
      shark(config-rtr)#redistribute static 
shark(config-rtr)#int g4/0/0
shark(config-if)#ipv6 rip rip enable
shark(config-if)#end
shark#
*Mar 16 21:51:55.235: %SYS-5-CONFIG_I: Configured from console by
console
shark#

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Thursday, March 17, 2011 2:03 PM
To: james woodyatt
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

James,

>> there are multiple proposals for zero configuration routing. as far
as I see there is no reason why we couldn't design a self configuring
network at layer 3.
> 
> RIPng is not zero-configuration.  Neither is OSPF.  Searching the
Internet draft archives, I find this abandoned draft from over ten years
ago, which is an example of the sort of proposal I'm expecting to see:

what is your plan to handle loops in your ND proxies network? there is a
reason that is experimental after all.

> That draft was Informational and never updated.  I can't find any
other references to zero-configuration routing anywhere in the Internet
draft archives or the RFC series.  If there are "multiple" proposals for
zero-configuration residential network routing protocols, then I'd like
to see them now, please.

http://datatracker.ietf.org/doc/search/?name=zerouter&rfcs=on&activeDraf
ts=on&oldDrafts=on
http://datatracker.ietf.org/doc/draft-dimitri-zospf/

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 17 Mar 2011 11:30:52 -0700

> what is your plan to handle loops in your ND proxies network? there is a reason that is experimental after all.

I imagine that loop avoidance with ND-proxy would probably require an extension to ICMPv6 that implements a spanning-tree protocol.

> [I wrote:]

That draft is newer.  From 2002.  Still, its DISCLAIMER reads as follows:

   This draft is a work in progress. Its purpose is to sketch a
   potential solution to the problem of router self-configuration and
   highlight some of the trade-offs. The hope is to gauge interest
   within the IETF community for solving the problem, and soliciting
   feedback and suggestions from the designers, implementers, and users
   of the protocols referred to within. The purpose of this draft is not
   to attempt to set in stone a complete solution to the problem.
   Criticism and feedback are welcome. All references to OSPF imply
   OSPFv3, unless stated otherwise.

It was never updated after that.  I was rather hoping to see, at minimum, a Standards Track draft already taken up as a working group item somewhere in the Routing area.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Mar 2011 08:28:34 +1300

> Agreed.  However the design team is stepping gingerly.   We first did a single IPv6 CE router in the home case which is the Basic IPv6 CE Router document in the RFC Editor Queue.  The bis document…

Nothing, I think. Until we have clarity on the issues
in draft-v6ops-multihoming-without-nat66 I don't see
what we can say, beyond MUST support multiple
prefixes and MAY support multiple WAN interfaces.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Mar 2011 20:43:17 +0100 (CET)

On Fri, 18 Mar 2011, Brian E Carpenter wrote:

> Nothing, I think. Until we have clarity on the issues in 
> draft-v6ops-multihoming-without-nat66 I don't see what we can say, 
> beyond MUST support multiple prefixes and MAY support multiple WAN 
> interfaces.

A long time ago I did exactly this scenario, moved an enterprise from 
PA-subnet1 from ISP1 to PA-subnet2 at ISP2 over one month period, and both 
needed to work, and both ISPs did uRPF checking.

I normally say that whatever process came up with the answer "policy 
routing" (routing based on source IP address) you made a serious mistake 
way before you came to that answer, but in this case I think it's actually 
a valid mechanism.

In the draft I didn't see any mention of it, was it considered and 
rejected?

If one CPE has two WAN links and it gets two different PD prefixes, then 
it can send traffic to each one based on source IP address. How this would 
be discovered in a two WAN CPE router scenario I don't have an answer for. 
Whatever is done, it would also cause suboptimal routing for one of the 
prefixes since traffic would be routed via whatever default gw the host 
chose.

The major problem I see is how the two different CPEs would discover each 
others PD prefixes so they can do source based routing.

... or am I totally out in my thinking, perhaps this has been discussed 
and rejected before?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Mar 2011 21:47:50 +0100

>... or am I totally out in my thinking, perhaps this has been discussed 

I played with this scenario as hobby project. As far as I know there are no
RFCs that really address this issue, so if there is enough interest they 
should be created. Otherwise, I guess I should just write an informational
RFC about it sometime.

My setting is the following:

+-------+               +-------+
| ISP A |               | ISP B |
+-------+               +-------+
    |                       |
    | Prefix A::/48         | Prefix B::/48
    |                       |
+-------+               +-------+
| CPE A |               | CPE B |
+-------+               |-------+
    |                       |
----+-----------+-----------+----
                |
            +---------+
            | Host H  | A::1 and B::1
            +---------+

My assumption is that both ISPs will do some kind of ingress filtering such
that ISP A will only accept packets with a source address from A::/48 and
ISP B will only accept packets with source address in B::/48.

Host H has IPv6 addresses from both prefixes and host H has no knowledge about
the network topology. It just has one or both of the CPEs as default router.

Where this will go wrong is that host H may send a packet with source A::1 and
an off-site destination address to CPE B, which will forward it to ISP B and
then ISP B will drop it because it does not accept the source address.

To make this work, CPE B forwards the packet to CPE A and sends a redirect
ICMP to host H. Next time host H will send a packet for that destination
directly to CPE A. Host behavior could be improved (that would require
some changes to the ND RFC) but the current situation is not bad.

For routers you need a new model for forwarding packets that also takes the
source address of a packet into account. I.e., it is not enough for a router
to just have a route to ::/0, it also needs to know for which prefixes that
route is valid. If you just replace the destination prefix in the FIB with a 
tuple consisting of a source prefix and destination prefix, then you are mostly
there.

Finally, it would be nice if CPE A can inform CPE B about prefix A::/48) and
vice versa. For that I modified my own RIPv6 implementation to also carry
source prefixes. 

With those changes this kind setup is essentially transparent to the host.
And does not require any addtional configuration (both CPEs can safely 
announce default routes for their own prefixes without any additional 
configuration).

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Mar 2011 13:56:44 -0700

What you're describing is RFC 3704, I think.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Mar 2011 22:09:29 +0100 (CET)

On Fri, 18 Mar 2011, Fred Baker wrote:

>> For routers you need a new model for forwarding packets that also takes 
>> the source address of a packet into account. I.e., it is not enough for 
>> a router to just have a route to ::/0, it also needs to know for which 
>> prefixes that route is valid. If you just replace the destination 
>> prefix in the FIB with a tuple consisting of a source prefix and 
>> destination prefix, then you are mostly there.

I wasn't aware that BCP38 and RFC3704 was the same document (from a quick 
look at it). Good to know.

The above is described in RFC3704 section 4.3.

What is not described in the document is how the policy routing should be 
done most efficiently in a multihomed multi-router/subnet scenario.

If a home gw receives multiple PD from multiple upstream routers, would it 
make sense to recommend that forwarding based on source address follows 
the same path as the prefix was handed out from, instead of looking at 
RA/RS information?

This would mean going away from the whole SLAAC/RA model for default route 
learning and using source based routing instead, at least for certain 
source prefixes.

Recipe for disaster?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Mar 2011 22:16:41 +0100

>What you're describing is RFC 3704, I think.

RFC 3704 is about ingress filtering. Section 4.3 deals with routing and 
suggests that you send packets to the right ISP. However, it doesn't say how
that should be done.

But it does say "This is not a complicated procedure, but requires careful
planning and configuration". My goal was to make this for simple networks
zero config.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Mar 2011 22:25:11 +0100

>learning and using source based routing instead, at least for certain 

I'd say that if a router gets information about a destination from a 
proper routing protocol, then it should ignore RA/RS information and just
rely on the routing protocol.

On the otherhand, when a router is supposed to behave like a host, and pay
attention to RA messages then it's up to the upstream routers to figure it
out.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Mar 2011 16:30:26 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mikael Abrahamsson
Sent: Friday, March 18, 2011 5:09 PM
To: Fred Baker (fred)
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>learning and using source based routing instead, at least for certain 

I don't see any recipe for disaster wrt to your example.  The SLAAC/RA
model relates to the IPv6 ND protocol specified in RFC 4861 and RFC 4861
has no mention of a default "route".  All ND has is a concept of default
"router(s)".  Thus when the home gw has to ship packets upstream, the
home gw ships data to the default router(s).   One can have the upstream
routers send MSR (RFC 4191) to the downstream router and thus the
network dispenses with any source based routing and also sends data to a
specific upstream router.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Mar 2011 22:35:37 +0100 (CET)

> specific upstream router.

I don't see how this solves the problem.

You need to send traffic sourced from PREFIX1 to ISP1 and PREFIX2 to ISP2, 
and I don't see any source based information being distributed using RFC 
4191?

How can you solve this without source based routing?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Mar 2011 16:56:45 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Friday, March 18, 2011 5:36 PM
To: Hemant Singh (shemant)
Cc: Fred Baker (fred); IPv6 Ops WG
Subject: RE: [v6ops] I-D

>and I don't see any source based information being distributed using
RFC 

If packet destination matches PREFIX1, the downstream home gw sends the
packet to upstream router connected to ISP1. If packet destination
matches PREFIX2, the downstream home gw sends the packet to upstream
router connected to ISP2.  If packet destination does not match either
of PREFIX1 or PREFIX2, the home gw checks if the destination matches the
MSR and ships the packet as per the MSR routing information to ISP1 or
ISP2.  The output network interface of the home gw is a host for IPv6
address acquisition and for MSR receive.  If none of the above matches
are encountered, how do you map a source on the home gw to the packet
destination?  Once we know the answer to this question, we can discuss
what to do.

Hemant

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Mar 2011 23:02:51 +0100

>destination?  Once we know the answer to this question, we can discuss

The issue, suppose the packet has destination D, which is neither in PREFIX1
nor in PREFIX2. The packet has a source addres S, which is either in PREFIX1
or in PREFIX2. If S is in PREFIX1, then the packet has to go to ISP1,
otherwise it will be discarded, and if S is in PREFIX2, it has to go to ISP2.

How do you make that work?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Mar 2011 23:03:25 +0100 (CET)

> destination?  Once we know the answer to this question, we can discuss

I still don't get it. I keep saying "sourced", you keep saying 
"destination".

When a host with an address from both PREFIX1 and PREFIX2 which resides on 
the same LAN, whereto should it send it's outgoing packets? If packets 
from PREFIX1 ends up on ISP2 it'll be uRPF filtered, and vice versa.

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Mar 2011 15:17:06 -0700

On Mar 18, 2011, at 2:09 PM, Mikael Abrahamsson wrote:

>>> For routers you need a new model for forwarding packets that also takes the source address of a packet into account. I.e., it is not enough for a router to just have a route to ::/0, it also needs to know for which prefixes that route is valid. If you just replace the destination prefix in the FIB with a tuple consisting of a source prefix and destination prefix, then you are mostly there.
> 
> I wasn't aware that BCP38 and RFC3704 was the same document (from a quick look at it). Good to know.

It's not, but it's related.

2827 Network Ingress Filtering: Defeating Denial of Service Attacks
     which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May
     2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by
     RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)

http://www.ietf.org/rfc/rfc3704.txt
3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
     March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
     BCP0084) (Status: BEST CURRENT PRACTICE)

> What is not described in the document is how the policy routing should be done most efficiently in a multihomed multi-router/subnet scenario.
> 
> If a home gw receives multiple PD from multiple upstream routers, would it make sense to recommend that forwarding based on source address follows the same path as the prefix was handed out from, instead of looking at RA/RS information?
> 
> This would mean going away from the whole SLAAC/RA model for default route learning and using source based routing instead, at least for certain source prefixes.
> 
> Recipe for disaster?

This takes me to a much larger topic, currently under discussion in shim6 under the rubric of "exit routing".

Policy routing, among other approaches used in routing, is a special case of multi-topology routing. If you look at OSPF, for example, it routes to a destination using one of N route tables; N normally equals one, but it is possible to set one up for each TOS value, and by extension, each DSCP. Multi-topology routing as implemented by Cisco (I haven't looked at my competitors, but I assume they are similar) allows you to use a DSCP as a selector, builds topologies for each of several overlaid networks, and lets the source use the DSCP to select which will be used. VoIP (EF) traffic might use a routing overlay that excludes long delay paths, while video uses an overlay that excludes low bandwidth or highly congested paths, for example.

Exit routing, the topic under discussion here and in shim6, wants to do something similar but using the source address as the selector. In short, if you use a source address within some stated prefix, you use a routing overlay for that prefix. In that routing overlay, the router, or at least the interface on the router, to the wrong ISP is not a part of the overlay and is therefore not reachable using the overlay.

I, as a research project, would like to expand the notion from "routing to a destination prefix as qualified by <>" to "routing a class of traffic". The traffic class might be defined by a tuple of (destination prefix, source prefix, {DSCPs}), where any of those might be "any". A link might have a metric of ((::, ::, {EF}), number), and be available for voice traffic from and to anywhere; an advertised "default route" to an ISP might have a tuple of {2000::/3, IA_PD, any}, and be a default route for unicast traffic (2000::/3) using a given set of source addresses (IA_PD) and any traffic class. In routing, we intersect them to infer that the link could be used for {2000::/3, IA_PD, {EF}} voice traffic from a given source address to any unicast route with the given metric, and then perform our routing calculations (in a manner not so different from OSPF's approach) accordingly. Obvious extensions include traffic from a given ingress AS to an exit AS; a route "to" a next hop AS becomes in some sense a route to the exit router to that AS, a route to a remote AS becomes a route to the next hop AS, and a route from an AS

There would be some interesting implications. uRPF in a symmetrically routed network becomes a thing of the past - if I spoof a prefix outside the IA_PD, there is simply no route. There could be issues in transit backbones (which are asymmetrically routed) as a result; the fact that I have not chosen to route to a given prefix that hasn't been announced to me doesn't mean that I can't receive from that prefix; the fact that it has been announced makes it valid from that perspective.

None of our routing protocols today do that. No, I have not applied for IPR on the concept. Someone else may have. If anyone does so after I send this note, this note is prior art.

If we want to get into routing protocol design - Fred, that includes you - I would suggest it belongs on a routing mailer such as [email-masked]. We could, however, discuss what we would like such a protocol to do.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Mar 2011 11:48:25 +1300

On 2011-03-19 11:03, Mikael Abrahamsson wrote:
...
> When a host with an address from both PREFIX1 and PREFIX2 which resides
> on the same LAN, whereto should it send it's outgoing packets? If
> packets from PREFIX1 ends up on ISP2 it'll be uRPF filtered, and vice
> versa.

Yes, that's the exit selection problem in a nutshell. Since we don't
have a standardised solution yet we can't specify it in
ipv6-cpe-router-bis. I expect it will have to be left for
ipv6-cpe-router-ter.

I think the continuation of the discussion belongs on a thread
for draft-v6ops-multihoming-without-nat66.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Mar 2011 17:52:26 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Philip Homburg
Sent: Friday, March 18, 2011 6:03 PM
To: Hemant Singh (shemant)
Cc: Mikael Abrahamsson; IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt 

>How do you make that work?

Configure PBR (Policy Based Routing) on the downstream home gw.  See the
route-map CLI on a Cisco router used with PBR. The destination D has got
to be mapped to a policy route.  If D does not match a PBR route, the
packet is dropped.  Alternatively, for example, the upstream router with
ISP1 sends an MSR to the downstream home gw with a route that matches
destination D.  Thus packets with source S and destination D will have
to go through the upstream router facing ISP1.  Fred has also explained
in more detail the scope of what one could do for such a scenario -
thanks, Fred.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 19 Mar 2011 06:05:43 +0100 (CET)

On Fri, 18 Mar 2011, Fred Baker wrote:

> If we want to get into routing protocol design - Fred, that includes you 
> - I would suggest it belongs on a routing mailer such as [email-masked]. 
> We could, however, discuss what we would like such a protocol to do.

I have subscribed to that group now.

I wouldn't want to build a huge transit network based on your suggestion, 
but I think it's needed for the home/SME. I also think to get a multihomed 
home (and enterprise) working properly, we do need this functionality in 
the long run.

What do you want to call it? PBRP? Policy Based Routing Protocol? (would 
be in the same class as IGP).

If routing protocols are extended do to PBR, should hosts listen to this? 
Or do we need to extend the RA/RS messages to include this information as 
well? Or should it be done in the MSR messages described by Hemat? Or do 
we just raise that we see a need for it, and punt it to some other WG?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Mar 2011 08:34:20 +1300

On 2011-03-19 18:05, Mikael Abrahamsson wrote:
>> If we want to get into routing protocol design - Fred, that includes
>> you - I would suggest it belongs on a routing mailer such as
>> [email-masked]. We could, however, discuss what we would like such a
>> protocol to do.
> 
> I wouldn't want to build a huge transit network based on your
> suggestion, but I think it's needed for the home/SME. I also think to
> get a multihomed home (and enterprise) working properly, we do need this
> functionality in the long run.
> 

Border Router Discovery Protocol? See draft-boot-brdp-framework

   Brian

> 
> If routing protocols are extended do to PBR, should hosts listen to
> this? Or do we need to extend the RA/RS messages to include this
> information as well? Or should it be done in the MSR messages described
> by Hemat? Or do we just raise that we see a need for it, and punt it to
> some other WG?
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 19 Mar 2011 21:00:01 +0100 (CET)

On Sun, 20 Mar 2011, Brian E Carpenter wrote:

>> What do you want to call it? PBRP? Policy Based Routing Protocol? 
>> (would be in the same class as IGP).
>

Ah. Good, we don't have to reinvent the wheel.

What is RENUM? The first hits says it's a non-wg email list?

Anyhow, BRDP looks exactly what I had in mind and a quick read through it 
seems they have already discussed and documented the features we need for 
all deployment scenarios that has come up in earlier discussions here?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Mar 2011 10:12:56 +1300

> What is RENUM? The first hits says it's a non-wg email list?

A BOF, in Prague.
http://www.ietf.org/mail-archive/web/ietf/current/msg65918.html

   Brian

> 
> Anyhow, BRDP looks exactly what I had in mind and a quick read through
> it seems they have already discussed and documented the features we need
> for all deployment scenarios that has come up in earlier discussions here?
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Mar 2011 14:53:52 +0100

> for draft-v6ops-multihoming-without-nat66.

+1
This draft is IMHO a good starting point.

It deals with hosts that know their global addresses, and know which next hop to use depending on their global source addresses. 
For ULA networks, a complement is AFAIK needed. 

RD

---

From: Tim Chown <[email-masked]>
Date: Mon, 21 Mar 2011 15:50:34 +0000

> For ULA networks, a complement is AFAIK needed. 

There's also other relevant material buried in the vaults of multi6 history, e.g. draft-huitema-multi6-hosts-03 and draft-huitema-multi6-ingress-filtering-00.

Tim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Mar 2011 15:41:28 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Saturday, March 19, 2011 3:34 PM
To: Mikael Abrahamsson
Cc: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>Border Router Discovery Protocol? See draft-boot-brdp-framework

I am not convinced that the document above, nor shim6 nor any other
source-based routing solution is needed just yet for the IPv6 CE Router.
Let's first solidify the multihomed requirements in the home for the
IPv6 CE router and then we can look at solutions.  We do hope to
solidify the requirements during the next few weeks.  For now I have
snipped the first multihomed diagram in the document mentioned above and
analyzed the network using existing protocols available. 

          /^^^^^^^^^^^^^^^^^^^^^^\
         /                        \
        {       The Internet       }
         \                        /
          \______________________/
           /                    \
          /(2001:08db:100::/40)  \(2001:8DB:200::/40)
     +=======+              +=======+
     [ ISP_1 ]              [ ISP_2 ]
     +=======+              +=======+
         |                       |
         |(2001:8DB:101::/48)    |(2001:8DB:201::/48)
   +--------+              +--------+
   | BR_101 |              | BR_201 |
   +--------+              +--------+
     | FE80::101/64            | FE80::201/64
     | 2001:8DB:101:1::101/64  | 2001:8DB:201:1::201/64
     |                         |
    -+---------------------+---+-
                           |
   2001:8DB:101:1::1234/64 | 2001:8DB:201:1::1234/64
             FE80::1234/64 |
                     +-----------+
                     | Host_1234 |
                     +-----------+

Let's consider the case that Host_1234 has to send a packet to a
destination D where D does not match any of 2001:8DB:101::/48 or
(2001:8DB:201::/48.  Also, let's assume it's only the BR_201 router path
that has a route to send the packet to destination D.  However, the
Host_1234 sent the packet with destination D with src of
2001:8DB:101:1::1234 and the packet reached BR_101. BR_101 does not drop
the packet because BR_101 runs an IGP between itself and BR_201 and thus
BR_101 knows that the packet can be forwarded to BR_201.  When BR_201
receives the packet, BR_201 forwards the packet upstream to ISP_2.
Also, when BR_101 forwards the packet to BR_201, BR_101 also sends a
Redirect to Host_1234 to send packets to such a destination via BR_201.
In the return path when some node in the Internet cloud replies to the
packet sent from the home, the packet is returned to Host_1234 on the
same path as the sent packet.  Alternatively, before the host sent out
any packet, the host has received a MSR (RFC 4191) for a route to
destination D and hence the host does not send the packet to BR_101 but
instead sends the packet to BR_201.  

Thus between, an IGP, MSR/Redirect, the multihomed network issue above
is resolved.  Also, if one does not want to use the Redirect, just send
the MSR to Host_1234.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Mar 2011 22:54:38 +0100 (CET)

On Tue, 22 Mar 2011, Hemant Singh (shemant) wrote:

> Also, let's assume it's only the BR_201 router path
> that has a route to send the packet to destination D.

I don't understand this scenario. In both scenarios, both BR will have 
"default route" to the "Internet", thus they have no idea if D is actually 
reachable via them or not.

> is resolved.  Also, if one does not want to use the Redirect, just send 

I don't understand the use-case you describe. The BCP38 filtering is based 
on source addresses, not destination.

In my world, both BR (CPEs) will just have default route towards their 
respective ISP, and they need to somehow figure out what source address of 
packets need to go out their ISP and which one needs to go to the others.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2011 11:31:25 +1300

> source-based routing solution is needed just yet for the IPv6 CE Router.

I agree. BRDP is far from cooked as an IETF solution. Shim6 is standardised,
but requires no special action by the CE router anyway.

> IPv6 CE router and then we can look at solutions.  

I assume you are now talking about a future draft and not about
cpe-router-bis?

> We do hope to

Again - this topic (and your analysis, if it's correct) seems to me to
belong in the multihoming-without-nat66 draft.

As I said a long time ago when MIF was first discussed, it seems that what
we need is to replace the concept of "default router" in the host stack
with a concept of "default router per prefix".

    Brian

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Mar 2011 17:40:57 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 5:55 PM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>reachable via them or not.

Is always possible to program a specific router on a ISP facing router
being managed by an ISP.  Use an Out of band means such as DHCPv6 or MSR
to program a specific route.  If none of such Out of band mechanisms are
possible, ISP_1 and ISP_2 routers send MSR downstream in the LAN.

>on source addresses, not destination.

We have already discussed last time on this thread that any of uRPF or
src filtering is relaxed for this analysis for data forwarding.

>packets need to go out their ISP and which one needs to go to the
others.

The interior routers should use MSR from the upstream router.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Mar 2011 18:44:20 -0500

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 6:31 PM
To: Hemant Singh (shemant)
Cc: Mikael Abrahamsson; IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>but requires no special action by the CE router anyway.

Ah, OK.  Sorry, I am behind on my reading and shim6 is one specification I have to go thru.  Anyone deploy shim6 yet in any SP/edge network?

>I assume you are now talking about a future draft and not about

I do think so - draft-cpe-router-ter should deal with multihoming and graphed routed topologies.  The reason is because the bis document is gestating to a critical mass for new requirements that would be worth publishing.  The routing section in section 5.4 has reached rough consensus in this mailer for text.  DNS is something we have to work on a bit.  Thereafter we could submit the bis document for LastCall.

>belong in the multihoming-without-nat66 draft.

Ah, OK.  

>with a concept of "default router per prefix".

When a host has to forward a packet to a destination, the destination is either on-link (if the destination matches a prefix in the host's ND Prefix List) or off-link that means the packet is shipped to default router(s).  Thus all I can see is a default routers(s) per destination, not prefix.   Note the MSR is a construct that can map a prefix to a default router where the default router in the router that sent the RA with the MSR. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Mar 2011 18:49:13 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 5:55 PM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>reachable via them or not.

Besides my other email reply, here is another observation.  With my
analysis, at least the packet sent to BR_101 got forwarded to BR_201
where BR_201 is the correct router to deal with packets sourced in the
2001:8DB:201::/48 subnet prefix.  Let BR_201 forward the packet to the
SP and SP should have a route to destination D. 

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2011 14:21:17 +1300

> Ah, OK.  Sorry, I am behind on my reading and shim6 is one specification I have to go thru.  Anyone deploy shim6 yet in any SP/edge network?

Only hosts deploy shim6 - there is nothing for router vendors or operators to do!

> When a host has to forward a packet to a destination, the destination is either on-link (if the destination matches a prefix in the host's ND Prefix List) or off-link that means the packet is shipp…

To avoid ingress filters, you have to hit the right exit router. The easiest
way to do that is to select the default router according to the *source*
prefix of the packet. MIF is talking about having a default router per
interface; I think the model has to be stronger, and make it per prefix.
You definitely need a strong host model of some kind. But at the moment
this isn't well defined, so v6ops can't specify it.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Mar 2011 05:38:08 +0100 (CET)

> src filtering is relaxed for this analysis for data forwarding.

That is not a real world scenario. Operators should definitely do uRPF 
based filtering and we cannot design scenarios where this is not done.

> The interior routers should use MSR from the upstream router.

It's my opinion that the draft should leave out the "multihoming with more 
than one router" scenario, since we can't make it work with current 
mechanisms. BCP38 style filtering is the reality and if we can't make 
things work with it, then it's not worth spending time on.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Mar 2011 09:28:56 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 12:38 AM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>based filtering and we cannot design scenarios where this is not done.

In the analysis I did yesterday for the multihomed topology, note the
interiors routers are not managed by any Operator.  It is silly for an
interior router such as the BR_101 to drop a packet with wrong source
due to ingress filtering or uRPF because BR_101 has learnt via an IGP
from BR_201 that the source matches a route BR_101 learnt.    

>things work with it, then it's not worth spending time on.

Yes, the -bis document is not going to address multihoming.  

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Mar 2011 16:08:39 +0100 (CET)

> from BR_201 that the source matches a route BR_101 learnt.

It's not the interior router that will drop it, it's the operator router 
it knows its default route from and thus is it's way out to the rest of 
the Internet.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Mar 2011 12:10:08 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 11:09 AM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; IPv6 Ops WG
Subject: RE: [v6ops] I-D

>the Internet.

Sorry, I don't understand.  In the picture reproduced below again, when
the packet with destination D sourced from host Host_1234 with src
address of 2001:8DB:201:1::1234 reaches BR_101, BR_101 forwards the
packet to BR_201 which is served by ISP_2.  BR_201 forwards the packet
to ISP_2 who has a default route and default router in the SP network.
Why wouldn't the ISP_2 router merely forward the packet to the SP?  Are
you saying ISP_2 drops the packet and if so why?  Or are you saying
somewhere north of ISP_2 some router drops the packet?  If so, why?

Thanks,

Hemant

          /^^^^^^^^^^^^^^^^^^^^^^\
         /                        \
        {       The Internet       }
         \                        /
          \______________________/
           /                    \

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Mar 2011 18:48:05 +0100 (CET)

On Wed, 23 Mar 2011, Hemant Singh (shemant) wrote:

> packet to BR_201 which is served by ISP_2.

"destination D" in this context is for me totally irrelevant. ALL traffic 
sourced from :201: needs to go to BR201, because ISP_1 will drop the 
packets if BR_101 tries to send it to ISP_1.

So totally ignoring WHERETO the packet is going (as long as it's using the 
default route), how does BR_101 know that packets with source address 
:201: needs to go to BR_201 (or host_1234 knows it needs to use BR_201 for 
all traffic sourced from the :201: prefix).

I don't get it. Everything I've read so far concerns destination based 
routing, but both ISP1 and ISP2 (and hence BR_101 and BR_201) sees the 
internet just as a default route and thus announces this to their LAN.

> BR_201 forwards the packet

---

From: james woodyatt <[email-masked]>
Date: Wed, 23 Mar 2011 11:16:42 -0700

On Mar 23, 2011, at 10:48 AM, Mikael Abrahamsson wrote:
>> [...] BR_101 forwards the packet to BR_201 [...].
> 
> [...] BR_101 tries to send it to ISP_1. [...]

Sigh.  If the BR_101 and BR_201 are receiving and processing one another's RA messages, then BR_101 and BR_201 could conspire to do what Hemant thinks they should do.  Like Mikael, I'm not sure how they would know to enter into such a conspiracy apart from expert manual configuration.

And once again, Brian Carpenter has already said what needs to be said about this.

> with a concept of "default router per prefix".

I concur.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Mar 2011 13:27:06 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Wednesday, March 23, 2011 2:17 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D
Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

>Sigh.  If the BR_101 and BR_201 are receiving and processing one
another's RA messages, 

The BR_101 and BR_201 are not receiving each other's RAs.  However, I am
saying an IGP is running between BR_101 and BR_201.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Mar 2011 19:30:06 +0100 (CET)

> saying an IGP is running between BR_101 and BR_201.

IGP does destination based routing, I don't see how the IGP helps.

The Internet is reached thru a default route, so all the IGP sees is one 
default route from BR_101 and one from BR_201.

How this helps with sourced based routing is beyond me.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Mar 2011 13:41:48 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 2:30 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Ops WG
Subject: Re: [v6ops] I-D

>How this helps with sourced based routing is beyond me.

You are correct.  Sorry, besides the IGP, an ACL has to be configured on
BR_101 on the LAN interface and this ACL checks for source as :201:
prefix and then ships the packet to BR_201 based on the route BR_101
learnt to BR_201 via the IGP.   An ACL looking for a specific source and
then forwarding the packet is indeed source-based routing and this
specific use of ACL and forwarding is PBR.   So my analysis has to be
tweaked for use of src-based PBR enabled on the LAN of BR_101 and
BR_201.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Mar 2011 14:41:55 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 2:30 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Ops WG
Subject: Re: [v6ops] I-D

>default route from BR_101 and one from BR_201.

This is one requirement I did not see that only one default route is
available.  I was working off of the case the BR_201 has also been
programmed (use MSR) with a specific route to D (which is our packet
destination) and thus the specific route to D also gets propagated via
the IGP to BR_101.  Thus when BR_101 sees the packet with destination D,
BR_101 has a route for D only thru BR_201 and thus BR_101 forwards the
packet to BR_201.

This confusion is why we need a very precise set of use cases for
multihoming defined and then once all use cases are agreed upon, we work
on the solutions.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Mar 2011 20:53:39 +0100 (CET)

> multihoming defined and then once all use cases are agreed upon, we work

I think your use case is excellent (the drawings etc), I just don't 
understand where D comes from.

D in this case is "any destination on the Internet and it's reached via 
default route", and D is thus reachable via both BR_101 and BR_201, but 
they have different uRPF filtering policies so source address of packets 
must be matched to the correct BR.

---

From: james woodyatt <[email-masked]>
Date: Wed, 23 Mar 2011 14:00:05 -0700

On Mar 23, 2011, at 12:53 , Mikael Abrahamsson wrote:
>> I was working off of the case the BR_201 has also been programmed (use MSR) with a specific route to D (which is our packet destination) and thus the specific route to D also gets propagated via the IGP to BR_101.
> 
> I just don't understand where D comes from.

Yes, I too would rather not be left guessing about why you're limiting yourself to the case where D is a destination in some manually configured "more specific" prefix.  Why is this usage scenario more relevant to our considerations than the case where D is a destination requiring the global default route to reach?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 24 Mar 2011 05:05:34 -0500

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 1:48 PM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; IPv6 Ops WG
Subject: RE: [v6ops] I-D

Question.  What happens if Host_1234 decides to configure a static IPv6
address (for any walled-garden services) in a PI space and then sends
packets upstream?  Src-based routing drops the packet.  Do any of the
src-based routing RFCs and proposals out there address such a use case
and if so how?

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Mar 2011 11:09:40 +0100 (CET)

> src-based routing RFCs and proposals out there address such a use case 

Why would any ISP accept sourced packets from a customer whereto there is 
no routing back for that IP space to that customer?

If this is PI space then there is routing torwards the customer for this, 
and uRPF will allow the packets to pass to the Internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2011 08:02:33 +1300

On 2011-03-24 23:09, Mikael Abrahamsson wrote:
>> Question.  What happens if Host_1234 decides to configure a static
>> IPv6 address (for any walled-garden services) in a PI space and then
>> sends packets upstream?  Src-based routing drops the packet.  Do any
>> of the src-based routing RFCs and proposals out there address such a
>> use case and if so how?
> 
> Why would any ISP accept sourced packets from a customer whereto there
> is no routing back for that IP space to that customer?
> 
> If this is PI space then there is routing torwards the customer for
> this, and uRPF will allow the packets to pass to the Internet.

Exactly. If you are a PI site you have to negotiate routing with
each of your providers. That's the price of PI, and the reason
it doesn't scale.

Anyway, the IETF is not in the business of making walled gardens work
properly. Walled gardens are not part of the Internet. Actually, I think
we'd probably prefer to break them ;-). More seriously, we decided to
engineer them properly for IPv6 - that is, by defining ULAs, which
explicitly are not to be routed by any provider.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Mar 2011 12:36:21 -0700

Hi Brian, 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian E Carpenter
> Sent: Thursday, March 24, 2011 12:03 PM
> To: Mikael Abrahamsson
> Cc: IPv6 Ops WG
> Subject: Re: [v6ops] I-D 

Well, if your site contracts with a (quasi)PI prefix
vendor, then it can tunnel its PI-addressed packets
out via any of its avaialbe ISPs since the outer
addresses of the tunneled packets are topologically
correct for the ISP.

That's not exactly PI, but a sort of "poor man's PI"
where the only coordination needed is with the
(quasi)PI prefix vendor, and any of the available
ISPs are used as simple transits.

Some people might like this approach and others might
not. But, it gives end sites something sort of like
PI without costing an arm and a leg and imposing an
undue scaling burden.

Thanks - Fred
[email-masked]