Subject: [homenet] routing requirements

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 14:32:10 -0400

I've caught up on some 300 messages about routing.  Here are the requirements I've gleaned.  Question marks are unclear to me, please help.

1.      Homenet router requirements

2.      When evaluating a solution, discuss whether it provides for:

3.      Reachability between all nodes in the home network.

a.       Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types.

4.      Border detection.

a.       Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net.  Or there may be no border, if no external connection has been established.

b.      Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability.

c.       May be discovered by routing protocol, or other means.

5.      Robust to routers being moved/added/removed/renumbered

a.       Convergence time a few minutes or less.

6.      No configuration required.

a.       We might tolerate? a single password being entered on each device.  Discuss.

7.      Best-path is a non-requirement.

8.      Support for multiple upstream networks is a requirement.

a.       Including wireless offload, video-only, and split-tunnel VPN scenarios.

b.      With separate routers to each.  Not multihomed off the same router.

c.       Prefix delegated from all ISPs (upstreams).

d.      ISP A is default.

e.       With only traffic destined to ISP B's prefix using that link.

f.       With a backup default to ISP B, if desired.  What is default condition?

g.      Source address selection is out of scope.  And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden).  Choosing which address to use to look up the destination address is out of scope.

9.      Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution).

10.  A host with mutliple upstream paths to the same destination should be able to use another in case on fails.

11.  Prevent looping.

12.  Prefix stability?

13.  Lightweight (cheap) implementation.

Let me know if I've missed, or mistated, anything.

Lee

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 21 Oct 2011 17:07:49 -0400

Hello Howard,

Thank you very much for the summary of messages.

A comment on item 12:
12.  Prefix stability?

SC>  I expect that 'Prefix Stability' is a requirement at home or small offices. Without prefix stability some of the applications will suddenly break when the old prefix expires and the new prefix becomes effective.

And question to the wg:

SC>  Is the expectation from homenet wg that all hosts will implement RFC 3484 ?

Do the current home IPv6 host products support  RFC 3484 ? [ I don't think so ]  So the host implementation change should be required if a host has to support multiple prefixes or I might be missing something?

Thanks,

-Samita

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Howard, Lee
Sent: Friday, October 21, 2011 11:32 AM
To: [email-masked]
Subject: [homenet] routing requirements

4.      Border detection.

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?

Lee

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 17:26:14 -0400

Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable?  All of the ones I can think of would be cases where I would expect a session to drop, but I'm sure that's a lack of creativity on my part.

Lee

From: Samita Chakrabarti [mailto:[email-masked]]
Sent: Friday, October 21, 2011 5:08 PM
To: Howard, Lee; [email-masked]
Subject: RE: routing requirements

Hello Howard,

A comment on item 12:
12.  Prefix stability?

And question to the wg:

Thanks,

-Samita

4.      Border detection.

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?

Lee

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 21 Oct 2011 19:18:22 -0500

Note the IETF IPv6 CE router specifies use of the ULA in the home to
keep the home network independent of the SP network.  This way my
computer at home can still print to the printer even when my SP IPv6
network is down.  We have said this multiple time in v6ops during
development of the IPv6 CE router RFC 6204.  I don't have the time to
read the copious emails of homenet, but seeing some emails here and
there I see homenet regressing on issues that are closed in the v6ops
IPv6 CE router document development.  Examples of issues homenet is
regressing on is ND Proxy and use of zospf for prefix delegation in the
LAN.   There was only one cell phone vendor who was asking us for ND
Proxy with a single /64 PD delegated to the phone.   We convinced the
vendor at the Prague IETF to abandon that idea because such a /64 would
need RA Proxy in the CE router and RA Proxy is not defined is any RFC.
Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633.
That is why ND Proxy was removed from the cpe rtr bis document. 

Zospf was also closed in v6ops that it's not possible to use for prefix
delegation in the LAN.   Here is an email to v6ops on closure on ospf
for prefix delegation.  

Hemant

---- begin snip ------------

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 1:26 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

>Can such a default be extensible to exchange different types of
information than just reachability? For example, can it propagate
information such as "this is a guest network and this is an internal
network" or "this is a prefix that I have tentatively >assigned but do
not own yet"? If not, then perhaps something more flexible like IS-IS
would be better.

Not possible because the proposal is not workable.   Someone brought up
using OSPFv3 for use in prefix delegation in the home LAN to our IETF
CPE router design team.  See the questions I asked followed by the
person's reply and my responses back to show no routing protocol can be
used to delegate prefixes in the LAN.  

I asked, HS: How do you know OSPF has converged before responding to
DHCPv6 PD requests?

Reply: The CE router SHOULD wait until two sequential link-state
advertisements have no link state  changes before delegating any
prefixes.  This allows time for OSPF to converge, and for the  router to
build a topology map.

Seeing the above reply, I made my comment:

HS: Still does not work.  After OSPF converges, what happens if the user
changes the network such  as unplugging a router and moving the router?

Reply: The router has a link state table-when it changes, you go through
discovery again and issue a  Reconfigure where appropriate.  

HS:  There is a network bridge between two routers and the bridge does
not have any means to report link-up  or down.  Further, what if a
network interface of a router is flapping all the time and thus  basing
any algorithm on OSPF convergence breaks down.  The flapping interface
problem becomes  worse if one has a cyclic network.  Your proposal still
does not work.  

Hemant

------ end snip ---------

 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Howard, Lee
Sent: Friday, October 21, 2011 5:26 PM
To: Samita Chakrabarti; [email-masked]
Subject: Re: [homenet] routing requirements

Can you describe some scenarios which would cause a prefix to change, in
which applications break in ways that are unacceptable?  All of the ones
I can think of would be cases where I would expect a session to drop,
but I'm sure that's a lack of creativity on my part.

Lee

Hello Howard,

A comment on item 12:

12.  Prefix stability? 

SC>  I expect that 'Prefix Stability' is a requirement at home or small
offices. Without prefix stability some of the applications will suddenly
break when the old prefix expires and the new prefix becomes effective.

And question to the wg:

g.      Source address selection is out of scope.  And should be solved
by rfc3484, with longest prefix match (whether ULA or walled garden).
Choosing which address to use to look up the destination address is out
of scope.

SC> Is the expectation from homenet wg that all hosts will implement RFC
3484 ?

Do the current home IPv6 host products support RFC 3484 ? [ I don't
think so ]  So the host implementation change should be required if a
host has to support multiple prefixes or I might be missing something?

Thanks,

-Samita

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Howard, Lee
Sent: Friday, October 21, 2011 11:32 AM
To: [email-masked]
Subject: [homenet] routing requirements

I've caught up on some 300 messages about routing.  Here are the
requirements I've gleaned.  Question marks are unclear to me, please
help.

a.       Links may be Ethernet, WiFi, MoCA, or any other; test all
solutions against mutliple L2 types.

4.      Border detection.  

a.       Border may be upstream ISP, or may be a device that is a
gateway to SmartGrid devices, e.g. a controller that speaks RPL to
802.15.4 and foo to home net.  Or there may be no border, if no external
connection has been established.  

b.      Must be able to find "up" (a path to the Internet), but must not
be dependent on "up" (Internet connectivity) existing for intra-home
reachability.

a.       We might tolerate? a single password being entered on each
device.  Discuss.

a.       Including wireless offload, video-only, and split-tunnel VPN
scenarios.  

b.      With separate routers to each.  Not multihomed off the same
router.

d.      ISP A is default.

f.       With a backup default to ISP B, if desired.  What is default
condition?

g.      Source address selection is out of scope.  And should be solved
by rfc3484, with longest prefix match (whether ULA or walled garden).
Choosing which address to use to look up the destination address is out
of scope.

9.      Cannot assume hierarchical prefix delegation in the home (at
least, not unless the WG develops such a solution).

10.  A host with mutliple upstream paths to the same destination should
be able to use another in case on fails. 

11.  Prevent looping.

12.  Prefix stability?  

Lee

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 21 Oct 2011 21:48:15 -0400

Thanks Hemant for the information from V6ops discussion on zospf prefix delegation.
In my humble view:
 - Prefix assignment should be independent  from a routing protocol
- Binding prefix-assignment to a routing protocol creates the problem of synchronization as you pointed out and also it limits the user to a single routing protocol for the network. I think the users/operators should have flexibility to choose a routing protocol for the services they offer today and in future.

I'd really like to see IPv6 PD solution for the home network for network stability after a power outage or bringing up a new set of network.
We have gone through similar debate in RPL development timeframe and finally as far as I know RPL made the prefix configuration optional.

If someone thinks that a new version of ospfv3 will introduce prefix assignment as a optional feature for a particular application/environment where it might work perfectly - I am okay with that. It is difficult for me to think OSPFv3 being the default choice to configure ip-addresses in a home network.
In future, home network will grow further  - I expect that there will be two kinds of users at home - 1)  tech-challenged users who like plug-n-play 2) tech-savvy users running business or running multi-level networks at home for convenience and pleasure or whatever reasons. So it'll be a combination of big and small ip-enabled devices and lots of them...

Regards,
-Samita

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, October 21, 2011 5:18 PM
To: Howard, Lee; Samita Chakrabarti; [email-masked]
Subject: Re: [homenet] routing requirements

Note the IETF IPv6 CE router specifies use of the ULA in the home to keep the home network independent of the SP network.  This way my computer at home can still print to the printer even when my SP IPv6 network is down.  We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204.  I don't have the time to read the copious emails of homenet, but seeing some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development.  Examples of issues homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN.   There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone.   We convinced the vendor at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC.  Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633.  That is why ND Proxy was removed from the cpe rtr bis document.

Zospf was also closed in v6ops that it's not possible to use for prefix delegation in the LAN.   Here is an email to v6ops on closure on ospf for prefix delegation.

Hemant

---- begin snip ------------

From: Lorenzo Colitti [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, July 27, 2011 1:26 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

>Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively >assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better.

Not possible because the proposal is not workable.   Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE router design team.  See the questions I asked followed by the person's reply and my responses back to show no routing protocol can be used to delegate prefixes in the LAN.

I asked, HS: How do you know OSPF has converged before responding to DHCPv6 PD requests?

Reply: The CE router SHOULD wait until two sequential link-state advertisements have no link state  changes before delegating any prefixes.  This allows time for OSPF to converge, and for the  router to build a topology map.

HS: Still does not work.  After OSPF converges, what happens if the user changes the network such  as unplugging a router and moving the router?

Reply: The router has a link state table-when it changes, you go through discovery again and issue a  Reconfigure where appropriate.

HS:  There is a network bridge between two routers and the bridge does not have any means to report link-up  or down.  Further, what if a network interface of a router is flapping all the time and thus  basing any algorithm on OSPF convergence breaks down.  The flapping interface problem becomes  worse if one has a cyclic network.  Your proposal still does not work.

Hemant

------ end snip ---------

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Howard, Lee
Sent: Friday, October 21, 2011 5:26 PM
To: Samita Chakrabarti; [email-masked]<mailto:[email-masked]>
Subject: Re: [homenet] routing requirements

Lee

From: Samita Chakrabarti [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, October 21, 2011 5:08 PM
To: Howard, Lee; [email-masked]<mailto:[email-masked]>
Subject: RE: routing requirements

Hello Howard,

A comment on item 12:
12.  Prefix stability?

And question to the wg:

Thanks,

-Samita

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Howard, Lee
Sent: Friday, October 21, 2011 11:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [homenet] routing requirements

4.      Border detection.

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?

Lee

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 21 Oct 2011 20:56:00 -0500

From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: Friday, October 21, 2011 9:48 PM
To: Hemant Singh (shemant); Howard, Lee; [email-masked]
Subject: RE: [homenet] routing requirements

>If someone thinks that a new version of ospfv3 will introduce prefix
assignment as a optional feature for a particular
application/environment where it might work perfectly - I am okay with
that. It is difficult for me >to think OSPFv3 being the default choice
to configure ip-addresses in a home network. 

A routing protocol is so not proper to use for prefix delegation in the
home LAN - it's like mixing oil and water.  That is why I sent that
v6ops email.   Before anyone embarks on any ospfv3 or any other routing
protocol based prefix delegation, please address what I raised for
concerns in my v6ops email. 

Regards,

Hemant

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 21 Oct 2011 22:03:19 -0400

>  Can you describe some scenarios which would cause a prefix to change, in which applications break in ways that are unacceptable?

1) See Hemanth's mail for a situation when a  routing protocol assigns ip-addresses after power failure or so
2) If the prefix assignment mechansim does not make sure that a device will be assigned the same address for a short power failure or short interruption of connectivity when your session is still alive (due to TCP session lifetime) , the interface might receive a new address/prefix and now depending on the prefix lifetime of the previous prefix, the session source address may become invalid and if that session is a VoIP/Streaming Video or critical healthcare related communication, one does not appreciate the drop of the session due to prefix instability.

 Regards,
-Samita

Hello Howard,

A comment on item 12:
12.  Prefix stability?

And question to the wg:

Thanks,

-Samita

4.      Border detection.

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?

Lee

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 21 Oct 2011 21:05:41 -0500

See how a network bridge/hub cause a problem in the home network.   It's
one thing that a Joe SixPack, or Grandma has a network bridge  behind
their CE router and the devices in the home are connected to the hub.  I
have personally seen a home with two broadband modems that were
connected to a hub that looped DAD messages back to the SP that totally
hosed the SP network interface for broadband IPv6 services.   See the
Introduction section of the following draft.  The second example is the
problem I speak of with the hub.

http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01

Thus anything homenet designs, do assume a home user can have a hub
anywhere in the network and protocols have to be designed for such a
network.  

Hemant

Lee

Hello Howard,

A comment on item 12:

12.  Prefix stability? 

And question to the wg:

 

Thanks,

-Samita

4.      Border detection.  

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?  

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 19:56:41 -0700

In message <[email-masked]>
Samita Chakrabarti writes:
 
> SC> offices. Without prefix stability some of the applications will
> SC> suddenly break when the old prefix expires and the new prefix
> SC> becomes effective.
>  
> And question to the wg:
>  
> g.  Source address selection is out of scope.  And should be solved by
> rfc3484, with longest prefix match (whether ULA or walled garden).
> Choosing which address to use to look up the destination address is
> out of scope.
>  
> SC> Is the expectation from homenet wg that all hosts will implement
> SC> RFC 3484 ?
>  
> SC> Do the current home IPv6 host products support RFC 3484 ? [ I
> SC> don't think so ] So the host implementation change should be
> SC> required if a host has to support multiple prefixes or I might be
> SC> missing something?
>  
> Thanks,
>  
> -Samita

A host can only be assigned multiple prefixes and have one essentially
"taken away" if it is know to be OK with it.

An extension (to an address allocation such as DHCP{4,6}) can easily
be crefted that allows the host to communicate the capability.  Prefix
stability is then only a requirement for the legacy hosts.  Any more
recent hosts can give up an address.

AFAIK all OS today support IPv6.  All recent hosts should support RFC
3484 (it is a 2003 RFC).  You'll still find some very old software out
there, so not all.  Worse than no IPv6 would be old broken IPv6 code.
I don't think this WG should focus on that small minority.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 20:13:38 -0700

In message <[email-masked]>
"Howard, Lee" writes:
 
> Can you describe some scenarios which would cause a prefix to change,
> in which applications break in ways that are unacceptable?  All of the
> ones I can think of would be cases where I would expect a session to
> drop, but I'm sure that's a lack of creativity on my part.
>  
> Lee

Most IPv4 hosts can't tolerate their IP address going away.  For IPv6
its slightly easier because they can add a new address in a new
prefix.  Only think is the host need to ask for an address and today
if its lease has not expired it won't ask.  Some older DHCP code won't
take a change in address or default route when the lease expires.

One thing that would break is any open TCP connections.  The open
connections use the already selected address.  This has been a problem
for mobility for quite a while but those heavier solution can't be
applied to this problem.

Concievably a TCP extension could support alternate source addresses
(such as SCTP does).  Until then, a TCP connection can't change
addresses.

If you switch from one provider uplink to another, you should be able
to keep talking to your content provider.  Currently you can't.  For
web users, hit the stop and the reload.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 21:13:58 -0700

Address assignment must be a separate protocol so that it is not tied
to one specific routing protocol.  OTOH it can (and IMO should) make
use of hints from the routing protocols at to where the uplinks are
and how close they are in selecting among available addresses.  For
IPv4 where DHCP likes to see one address only, supporting legacy hosts
is a harder problem.

Any extension mean that accomodation have to be made for legacy hosts.

Curtis

In message <[email-masked]>
Samita Chakrabarti writes:

--===============2644728098816532559==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_"

--_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Hemant for the information from V6ops discussion on zospf prefix del=
egation.
In my humble view:
 - Prefix assignment should be independent  from a routing protocol
- Binding prefix-assignment to a routing protocol creates the problem of sy=
nchronization as you pointed out and also it limits the user to a single ro=
uting protocol for the network. I think the users/operators should have fle=
xibility to choose a routing protocol for the services they offer today and=
 in future.

I'd really like to see IPv6 PD solution for the home network for network st=
ability after a power outage or bringing up a new set of network.
We have gone through similar debate in RPL development timeframe and finall=
y as far as I know RPL made the prefix configuration optional.

If someone thinks that a new version of ospfv3 will introduce prefix assign=
ment as a optional feature for a particular application/environment where i=
t might work perfectly - I am okay with that. It is difficult for me to thi=
nk OSPFv3 being the default choice to configure ip-addresses in a home netw=
ork.
In future, home network will grow further  - I expect that there will be tw=
o kinds of users at home - 1)  tech-challenged users who like plug-n-play 2=
) tech-savvy users running business or running multi-level networks at home=
 for convenience and pleasure or whatever reasons. So it'll be a combinatio=
n of big and small ip-enabled devices and lots of them...

Regards,
-Samita

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Hemant Singh (shemant)
Sent: Friday, October 21, 2011 5:18 PM
To: Howard, Lee; Samita Chakrabarti; [email-masked]
Subject: Re: [homenet] routing requirements

Note the IETF IPv6 CE router specifies use of the ULA in the home to keep t=
he home network independent of the SP network.  This way my computer at hom=
e can still print to the printer even when my SP IPv6 network is down.  We =
have said this multiple time in v6ops during development of the IPv6 CE rou=
ter RFC 6204.  I don't have the time to read the copious emails of homenet,=
 but seeing some emails here and there I see homenet regressing on issues t=
hat are closed in the v6ops IPv6 CE router document development.  Examples =
of issues homenet is regressing on is ND Proxy and use of zospf for prefix =
delegation in the LAN.   There was only one cell phone vendor who was askin=
g us for ND Proxy with a single /64 PD delegated to the phone.   We convinc=
ed the vendor at the Prague IETF to abandon that idea because such a /64 wo=
uld need RA Proxy in the CE router and RA Proxy is not defined is any RFC. =
 Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633.  That =
is why ND Proxy was removed from the cpe rtr bis document.

Zospf was also closed in v6ops that it's not possible to use for prefix del=
egation in the LAN.   Here is an email to v6ops on closure on ospf for pref=
ix delegation.

Hemant

---- begin snip ------------

From: Lorenzo Colitti [mailto:[email-masked]]<mailto:[mailto:lorenzo@go=
ogle.com]>
Sent: Wednesday, July 27, 2011 1:26 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

>Can such a default be extensible to exchange different types of informatio=
n than just reachability? For example, can it propagate information such as=
 "this is a guest network and this is an internal network" or "this is a pr=
efix that I have tentatively >assigned but do not own yet"? If not, then pe=
rhaps something more flexible like IS-IS would be better.

Not possible because the proposal is not workable.   Someone brought up usi=
ng OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE rout=
er design team.  See the questions I asked followed by the person's reply a=
nd my responses back to show no routing protocol can be used to delegate pr=
efixes in the LAN.

I asked, HS: How do you know OSPF has converged before responding to DHCPv6=
 PD requests?

Reply: The CE router SHOULD wait until two sequential link-state advertisem=
ents have no link state  changes before delegating any prefixes.  This allo=
ws time for OSPF to converge, and for the  router to build a topology map.

HS: Still does not work.  After OSPF converges, what happens if the user ch=
anges the network such  as unplugging a router and moving the router?

Reply: The router has a link state table-when it changes, you go through di=
scovery again and issue a  Reconfigure where appropriate.

HS:  There is a network bridge between two routers and the bridge does not =
have any means to report link-up  or down.  Further, what if a network inte=
rface of a router is flapping all the time and thus  basing any algorithm o=
n OSPF convergence breaks down.  The flapping interface problem becomes  wo=
rse if one has a cyclic network.  Your proposal still does not work.

Hemant

------ end snip ---------

From: [email-masked]<mailto:[email-masked]> [mailto:hom=
[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf =
Of Howard, Lee
Sent: Friday, October 21, 2011 5:26 PM
To: Samita Chakrabarti; [email-masked]<mailto:[email-masked]>
Subject: Re: [homenet] routing requirements

Can you describe some scenarios which would cause a prefix to change, in wh=
ich applications break in ways that are unacceptable?  All of the ones I ca=
n think of would be cases where I would expect a session to drop, but I'm s=
ure that's a lack of creativity on my part.

Lee

From: Samita Chakrabarti [mailto:[email-masked]]<mailto:[m=
ailto:[email-masked]]>
Sent: Friday, October 21, 2011 5:08 PM
To: Howard, Lee; [email-masked]<mailto:[email-masked]>
Subject: RE: routing requirements

Hello Howard,

A comment on item 12:
12.  Prefix stability?

SC>  I expect that 'Prefix Stability' is a requirement at home or small off=
ices. Without prefix stability some of the applications will suddenly break=
 when the old prefix expires and the new prefix becomes effective.

And question to the wg:

g.      Source address selection is out of scope.  And should be solved by =
rfc3484, with longest prefix match (whether ULA or walled garden).  Choosin=
g which address to use to look up the destination address is out of scope.

SC> Is the expectation from homenet wg that all hosts will implement RFC 34=
84 ?

Do the current home IPv6 host products support RFC 3484 ? [ I don't think s=
o ]  So the host implementation change should be required if a host has to =
support multiple prefixes or I might be missing something?

Thanks,

-Samita

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:hom=
[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf =
Of Howard, Lee
Sent: Friday, October 21, 2011 11:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [homenet] routing requirements

I've caught up on some 300 messages about routing.  Here are the requiremen=
ts I've gleaned.  Question marks are unclear to me, please help.

a.       Links may be Ethernet, WiFi, MoCA, or any other; test all solution=
s against mutliple L2 types.

4.      Border detection.

a.       Border may be upstream ISP, or may be a device that is a gateway t=
o SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo =
to home net.  Or there may be no border, if no external connection has been=
 established.

b.      Must be able to find "up" (a path to the Internet), but must not be=
 dependent on "up" (Internet connectivity) existing for intra-home reachabi=
lity.

a.       We might tolerate? a single password being entered on each device.=
  Discuss.

a.       Including wireless offload, video-only, and split-tunnel VPN scena=
rios.

d.      ISP A is default.

f.       With a backup default to ISP B, if desired.  What is default condi=
tion?

g.      Source address selection is out of scope.  And should be solved by =
rfc3484, with longest prefix match (whether ULA or walled garden).  Choosin=
g which address to use to look up the destination address is out of scope.

9.      Cannot assume hierarchical prefix delegation in the home (at least,=
 not unless the WG develops such a solution).

10.  A host with mutliple upstream paths to the same destination should be =
able to use another in case on fails.

11.  Prevent looping.

12.  Prefix stability?

Lee

________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6002.18494" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page WordSection1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times Ne=
w Roman","serif"; mso-style-priority: 99; mso-style-link: "Plain Text Char"
}
LI.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times Ne=
w Roman","serif"; mso-style-priority: 99; mso-style-link: "Plain Text Char"
}
DIV.MsoPlainText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times Ne=
w Roman","serif"; mso-style-priority: 99; mso-style-link: "Plain Text Char"
}
P.MsoAcetate {
	FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; m=
so-style-priority: 99; mso-style-link: "Balloon Text Char"
}
LI.MsoAcetate {
	FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; m=
so-style-priority: 99; mso-style-link: "Balloon Text Char"
}
DIV.MsoAcetate {
	FONT-SIZE: 8pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; m=
so-style-priority: 99; mso-style-link: "Balloon Text Char"
}
P.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 10pt 0.5in; LINE-HEIGHT: 115%; FONT-FAMIL=
Y: "Times New Roman","serif"; mso-style-priority: 34
}
LI.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 10pt 0.5in; LINE-HEIGHT: 115%; FONT-FAMIL=
Y: "Times New Roman","serif"; mso-style-priority: 34
}
DIV.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 10pt 0.5in; LINE-HEIGHT: 115%; FONT-FAMIL=
Y: "Times New Roman","serif"; mso-style-priority: 34
}
SPAN.PlainTextChar {
	COLOR: black; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: =
99; mso-style-link: "Plain Text"; mso-style-name: "Plain Text Char"
}
SPAN.EmailStyle20 {
	FONT-WEIGHT: normal; COLOR: black; FONT-STYLE: normal; FONT-FAMILY: "Times=
 New Roman","serif"; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: perso=
nal-reply
}
SPAN.BalloonTextChar {
	FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; mso-style-link=
: "Balloon Text"; mso-style-name: "Balloon Text Char"
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.WordSection1 {
	page: WordSection1
}
</STYLE>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D738232401-22102011></SPAN><FONT face=3DArial color=3D#00=
00ff=20
size=3D2>Thanks&nbsp;Hemant&nbsp;for&nbsp;the&nbsp;information&nbsp;<SPAN=20
class=3D738232401-22102011>from=20
</SPAN>V6ops&nbsp;discussion&nbsp;on&nbsp;zospf&nbsp;prefix&nbsp;delegation=
.</FONT></DIV>
<DIV><FONT><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT><SPAN=20
class=3D738232401-22102011></SPAN><FONT face=3DArial><FONT color=3D#0000ff>=
<FONT=20
size=3D2>I<SPAN class=3D738232401-22102011>n my humble=20
view:</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT><SPAN=20
class=3D738232401-22102011></SPAN><FONT face=3DArial><FONT color=3D#0000ff>=
<FONT=20
size=3D2>&nbsp;<SPAN class=3D738232401-22102011>- Prefix assignment should=
=20
be&nbsp;independent &nbsp;from a routing=20
protocol</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT><SPAN=20
class=3D738232401-22102011></SPAN><FONT face=3DArial><FONT color=3D#0000ff>=
<FONT=20
size=3D2>-<SPAN class=3D738232401-22102011> Binding prefix-assignment to a =
routing=20
protocol creates the problem of synchronization as you pointed out and also=
 it=20
limits the user to a single routing protocol for the network. I think the=20
users/operators should have flexibility to choose a routing protocol for th=
e=20
services they offer today and in future.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>I'd really like to see IPv6 PD solution for the =
home=20
network for network stability after a power outage or bringing up a new set=
 of=20
network.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>We have gone through similar debate in RPL devel=
opment=20
timeframe and finally as far as I know RPL made the prefix configuration=20
optional.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>If someone thinks that a new version of ospfv3 w=
ill=20
introduce prefix assignment as a optional feature for a particular=20
application/environment where it might work perfectly - I am okay with that=
. It=20
is difficult for me to think OSPFv3 being the default choice to configure=20
ip-addresses in a home network. </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>In future, home network will grow further&nbsp; =
- I=20
expect that there will be two kinds of users at home - 1)&nbsp; tech-challe=
nged=20
users who like plug-n-play 2) tech-savvy users running business or running=
=20
multi-level networks at home for convenience and pleasure or whatever reaso=
ns.=20
So it'll be a combination of big and small ip-enabled devices and lots of=20
them...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>Regards,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D738232401-22102011>-Samita</SPAN></FONT></FONT></FONT></DIV>
<DIV><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Hemant Singh=20
(shemant)<BR><B>Sent:</B> Friday, October 21, 2011 5:18 PM<BR><B>To:</B> Ho=
ward,=20
Lee; Samita Chakrabarti; [email-masked]<BR><B>Subject:</B> Re: [homenet]=
=20
routing requirements<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DWordSection1>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Note the IETF IPv6 CE r=
outer=20
specifies use of the ULA in the home to keep the home network independent o=
f the=20
SP network.&nbsp; This way my computer at home can still print to the print=
er=20
even when my SP IPv6 network is down.&nbsp; We have said this multiple time=
 in=20
v6ops during development of the IPv6 CE router RFC 6204.&nbsp; I don&#8217;=
t have the=20
time to read the copious emails of homenet, but seeing some emails here and=
=20
there I see homenet regressing on issues that are closed in the v6ops IPv6 =
CE=20
router document development.&nbsp; Examples of issues homenet is regressing=
 on=20
is ND Proxy and use of zospf for prefix delegation in the LAN.&nbsp; &nbsp;=
There=20
was only one cell phone vendor who was asking us for ND Proxy with a single=
 /64=20
PD delegated to the phone.&nbsp;&nbsp; We convinced the vendor at the Pragu=
e=20
IETF to abandon that idea because such a /64 would need RA Proxy in the CE=
=20
router and RA Proxy is not defined is any RFC.&nbsp; Thus the vendor agreed=
 and=20
decided to go with DHCPv6 PD of RC 3633.&nbsp; That is why ND Proxy was rem=
oved=20
from the cpe rtr bis document. <o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Zospf was also closed i=
n v6ops=20
that it&#8217;s not possible to use for prefix delegation in the LAN. &nbsp=
;&nbsp;Here=20
is an email to v6ops on closure on ospf for prefix delegation.&nbsp;=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Hemant<o:p></o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">---- begin snip=20
------------<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN><=
/B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Lorenzo Coli=
tti <A=20
href=3D"mailto:[mailto:[email-masked]]">[mailto:[email-masked]]</A>=
=20
<BR><B>Sent:</B> Wednesday, July 27, 2011 1:26 PM<BR><B>To:</B> Hemant Sing=
h=20
(shemant)<BR><B>Cc:</B> IPv6 Operations<BR><B>Subject:</B> Re: [v6ops] defa=
ult=20
LAN routing protocol for IPv6 CE router<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p>&nbs=
p;</o:p></SPAN></P>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">&gt;</SPAN>Can such a d=
efault be=20
extensible to exchange different types of information than just reachabilit=
y?=20
For example, can it propagate information such as "this is a guest network =
and=20
this is an internal network" or "this is a prefix that I have tentatively <=
SPAN=20
style=3D"COLOR: #1f497d">&gt;</SPAN>assigned but do not own yet"? If not, t=
hen=20
perhaps something more flexible like IS-IS would be better.<SPAN=20
style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Not possible because th=
e=20
proposal is not workable. &nbsp;&nbsp;Someone brought up using OSPFv3 for u=
se in=20
prefix delegation in the home LAN to our IETF CPE router design team.&nbsp;=
 See=20
the questions I asked followed by the person&#8217;s reply and my responses=
 back to=20
show no routing protocol can be used to delegate prefixes in the LAN.=20
&nbsp;<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">I asked, HS: How do you=
 know=20
OSPF has converged before responding to DHCPv6 PD=20
requests?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Reply: The CE router SH=
OULD wait=20
until two sequential link-state advertisements have no link state &nbsp;cha=
nges=20
before delegating any prefixes.&nbsp; This allows time for OSPF to converge=
, and=20
for the &nbsp;router to build a topology map.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Seeing the above reply,=
 I made=20
my comment:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">HS: Still does not work=
.&nbsp;=20
After OSPF converges, what happens if the user changes the network such &nb=
sp;as=20
unplugging a router and moving the router?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Reply: The router has a=
 link=20
state table&#8212;when it changes, you go through discovery again and issue=
 a=20
&nbsp;Reconfigure where appropriate.&nbsp; <o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">HS: &nbsp;There is a ne=
twork=20
bridge between two routers and the bridge does not have any means to report=
=20
link-up &nbsp;or down.&nbsp; Further, what if a network interface of a rout=
er is=20
flapping all the time and thus &nbsp;basing any algorithm on OSPF convergen=
ce=20
breaks down.&nbsp; The flapping interface problem becomes &nbsp;worse if on=
e has=20
a cyclic network.&nbsp; Your proposal still does not work.&nbsp;=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">Hemant<o:p></o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d">------ end snip=20
---------<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<P class=3DMsoNormal><SPAN style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN=
></P>
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df=
 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium non=
e; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN><=
/B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> <A=20
href=3D"mailto:[email-masked]">[email-masked]</A> <A=20
href=3D"mailto:[mailto:[email-masked]]">[mailto:homenet-bounces@i=
etf.org]</A>=20
<B>On Behalf Of </B>Howard, Lee<BR><B>Sent:</B> Friday, October 21, 2011 5:=
26=20
PM<BR><B>To:</B> Samita Chakrabarti; <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B>Subject:</B> Re=
:=20
[homenet] routing requirements<o:p></o:p></SPAN></P></DIV></DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'">Can=20
you describe some scenarios which would cause a prefix to change, in which=
=20
applications break in ways that are unacceptable? &nbsp;All of the ones I c=
an=20
think of would be cases where I would expect a session to drop, but I&#8217=
;m sure=20
that&#8217;s a lack of creativity on my part.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'">Lee<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium =
none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid=
; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df=
 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium non=
e; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN><=
/B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Samita Chakr=
abarti=20
<A=20
href=3D"mailto:[mailto:[email-masked]]">[mailto:samita.cha=
[email-masked]]</A>=20
<BR><B>Sent:</B> Friday, October 21, 2011 5:08 PM<BR><B>To:</B> Howard, Lee=
; <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B>Subject:</B> RE=
:=20
routing requirements<o:p></o:p></SPAN></P></DIV></DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">H=
ello=20
Howard,</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">&nbsp;<o:=
p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">T=
hank=20
you very much for the summary of messages.</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">&nbsp;<o:=
p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">A=
=20
comment on item 12:</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'">12.</SPAN><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: black; FONT-FAMILY: 'Times New Roman','seri=
f'">&nbsp;=20
</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New Roman','ser=
if'">Prefix=20
stability?&nbsp;</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">&nbsp;<o:=
p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">S=
C&gt;&nbsp;=20
I expect that 'Prefix Stability' is a requirement at home or small offices.=
=20
Without prefix stability some of the applications will suddenly break when =
the=20
old prefix expires and the new prefix becomes effective.</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">&nbsp;<o:=
p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">A=
nd=20
question to the wg:</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in"><SPAN=20
style=3D"COLOR: blue">8.</SPAN><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: blue; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
</SPAN><SPAN style=3D"COLOR: blue">Support for multiple upstream networks i=
s a=20
requirement.<o:p></o:p></SPAN></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
"><SPAN=20
style=3D"COLOR: blue">g.</SPAN><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: blue; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
</SPAN><SPAN style=3D"COLOR: blue">Source address selection is out of scope=
.&nbsp;=20
And should be solved by rfc3484, with longest prefix match (whether ULA or=
=20
walled garden).&nbsp; Choosing which address to use to look up the destinat=
ion=20
address is out of scope.</SPAN><o:p></o:p></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
"><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; LINE-HEIGHT: 115%; FONT-FAMILY: 'Ari=
al','sans-serif'">SC&gt;=20
Is the expectation from homenet wg that all hosts will implement RFC 3484=20
?</SPAN><o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
"><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; LINE-HEIGHT: 115%; FONT-FAMILY: 'Ari=
al','sans-serif'">Do=20
the current home IPv6 host products support RFC 3484 ? [ I don't think so=20
]&nbsp; So the host implementation change&nbsp;should be required&nbsp;if a=
 host=20
has to support multiple prefixes or I might be missing=20
something?</SPAN><o:p></o:p></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
"><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; LINE-HEIGHT: 115%; FONT-FAMILY: 'Ari=
al','sans-serif'">Thanks,</SPAN><o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
"><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; LINE-HEIGHT: 115%; FONT-FAMILY: 'Ari=
al','sans-serif'">-Samita</SPAN><o:p></o:p></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<P class=3DMsoListParagraph=20
style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in">&nbsp;<o:p></o:p></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">
<HR align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN><=
/B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> <A=20
href=3D"mailto:[email-masked]">[email-masked]</A> <A=20
href=3D"mailto:[mailto:[email-masked]]">[mailto:homenet-bounces@i=
etf.org]</A>=20
<B>On Behalf Of </B>Howard, Lee<BR><B>Sent:</B> Friday, October 21, 2011 11=
:32=20
AM<BR><B>To:</B> <A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B>Subject:</B> [h=
omenet]=20
routing requirements</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P>
<P class=3DMsoPlainText>I've caught up on some 300 messages about routing.&=
nbsp;=20
Here are the requirements I've gleaned.&nbsp; Question marks are unclear to=
 me,=20
please help.<o:p></o:p></P>
<P class=3DMsoPlainText><o:p>&nbsp;</o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">1.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Homenet router requirements<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">2.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>When evaluating a solution, discuss whether it provides=20
for:<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">3.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Reachability between all nodes in the home network.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">a.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>Links may be Ethernet, WiFi, MoCA, or any other; test all solutions=
=20
against mutliple L2 types.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">4.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Border detection.&nbsp; <o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">a.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>Border may be upstream ISP, or may be a device that is a gateway to=
=20
SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and <I>foo=
</I>=20
to home net.&nbsp; Or there may be no border, if no external connection has=
 been=20
established.&nbsp; <o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">b.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Must be able to find &#8220;up&#8221; (a path to the Internet), but =
must not be=20
dependent on &#8220;up&#8221; (Internet connectivity) existing for intra-ho=
me=20
reachability.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">c.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>May be discovered by routing protocol, or other means.<o:p></o:p></P=
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">5.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Robust to routers being moved/added/removed/renumbered<o:p></o:p></P=
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">a.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>Convergence time a few minutes or less.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">6.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>No configuration required.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">a.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>We might tolerate? a single password being entered on each device.&n=
bsp;=20
Discuss.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">7.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Best-path is a non-requirement.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">8.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Support for multiple upstream networks is a requirement.<o:p></o:p><=
/P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">a.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>Including wireless offload, video-only, and split-tunnel VPN=20
scenarios.&nbsp; <o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">b.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>With separate routers to each.&nbsp; Not multihomed off the same=20
router.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">c.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>Prefix delegated from all ISPs (upstreams).<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">d.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>ISP A is default.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">e.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>With only traffic destined to ISP B&#8217;s prefix using that=20
link.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">f.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
</SPAN>With a backup default to ISP B, if desired.&nbsp; What is default=20
condition?<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"MARGIN-LEFT: 1in; TEXT-INDENT: -0.25in=
">g.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Source address selection is out of scope.&nbsp; And should be solved=
 by=20
rfc3484, with longest prefix match (whether ULA or walled garden).&nbsp;=20
Choosing which address to use to look up the destination address is out of=
=20
scope.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">9.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN>Cannot assume hierarchical prefix delegation in the home (at least, =
not=20
unless the WG develops such a solution).<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">10.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp; </SPAN>A host with mutli=
ple=20
upstream paths to the same destination should be able to use another in cas=
e on=20
fails. <o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">11.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp; </SPAN>Prevent=20
looping.<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">12.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp; </SPAN>Prefix stability?=
&nbsp;=20
<o:p></o:p></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -0.25in">13.<SPAN=20
style=3D"FONT-SIZE: 7pt; LINE-HEIGHT: 115%">&nbsp; </SPAN>Lightweight (chea=
p)=20
implementation.<o:p></o:p></P>
<P class=3DMsoPlainText>Let me know if I&#8217;ve missed, or mistated,=20
anything.<o:p></o:p></P>
<P class=3DMsoPlainText><o:p>&nbsp;</o:p></P>
<P class=3DMsoPlainText>Lee<o:p></o:p></P>
<P class=3DMsoPlainText><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p>&nbs=
p;</o:p></SPAN></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">
<HR align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></DIV>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: gray; FONT-FAMILY: 'Arial','sans-serif'">=
This=20
E-mail and any of its attachments may contain Time Warner Cable proprietary=
=20
information, which is privileged, confidential, or subject to copyright=20
belonging to Time Warner Cable. This E-mail is intended solely for the use =
of=20
the individual or entity to which it is addressed. If you are not the inten=
ded=20
recipient of this E-mail, you are hereby notified that any dissemination,=20
distribution, copying, or action taken in relation to the contents of and=20
attachments to this E-mail is strictly prohibited and may be unlawful. If y=
ou=20
have received this E-mail in error, please notify the sender immediately an=
d=20
permanently delete the original and any copy of this E-mail and any=20
printout.</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'"><o:p></o:=
p></SPAN></P></DIV></DIV></BODY></HTML>

--_000_16D60F43CA0B724F8052D7E9323565D7243F7EB191EUSAACMS0715e_--

--===============2644728098816532559==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2644728098816532559==--

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 08:24:16 +0000

On 22 Oct 2011, at 01:18, Hemant Singh (shemant) wrote:

Note the IETF IPv6 CE router specifies use of the ULA in the home to keep the home network independent of the SP network.  This way my computer at home can still print to the printer even when my SP IPv6 network is down.  We have said this multiple time in v6ops during development of the IPv6 CE router RFC 6204.

Thanks for the reminder.  FWIW, I believe the consensus _is_ for ULAs within the home network, although I do see a few vocal opponents.

I don’t have the time to read the copious emails of homenet, but seeing some emails here and there I see homenet regressing on issues that are closed in the v6ops IPv6 CE router document development.  Examples of issues homenet is regressing on is ND Proxy and use of zospf for prefix delegation in the LAN.   There was only one cell phone vendor who was asking us for ND Proxy with a single /64 PD delegated to the phone.   We convinced the vendor at the Prague IETF to abandon that idea because such a /64 would need RA Proxy in the CE router and RA Proxy is not defined is any RFC.  Thus the vendor agreed and decided to go with DHCPv6 PD of RC 3633.  That is why ND Proxy was removed from the cpe rtr bis document.

Will those arguing for ND Proxy please stand up and be counted?

Zospf was also closed in v6ops that it’s not possible to use for prefix delegation in the LAN.   Here is an email to v6ops on closure on ospf for prefix delegation.

Again, thanks, that's useful background.

Ray

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 24 Oct 2011 06:27:15 -0700

On Oct 24, 2011 1:24 AM, "Ray Bellis" <[email-masked]> wrote:
>> Note the IETF IPv6 CE router specifies use of the ULA in the home to keep
the home network independent of the SP network.  This way my computer at
home can still print to the printer even when my SP IPv6 network is down.
We have said this multiple time in v6ops during development of the IPv6 CE
router RFC 6204.
>
>
> Thanks for the reminder.  FWIW, I believe the consensus _is_ for ULAs
within the home network, although I do see a few vocal opponents.
>
>> I don’t have the time to read the copious emails of homenet, but seeing
some emails here and there I see homenet regressing on issues that are
closed in the v6ops IPv6 CE router document development.  Examples of issues
homenet is regressing on is ND Proxy and use of zospf for prefix delegation
in the LAN.   There was only one cell phone vendor who was asking us for ND
Proxy with a single /64 PD delegated to the phone.   We convinced the vendor
at the Prague IETF to abandon that idea because such a /64 would need RA
Proxy in the CE router and RA Proxy is not defined is any RFC.  Thus the
vendor agreed and decided to go with DHCPv6 PD of RC 3633.  That is why ND
Proxy was removed from the cpe rtr bis document.
> Will those arguing for ND Proxy please stand up and be counted?

I am not arguing for ND proxy, just saying the mobile device may use it to
extend their connectivity into the house. So I am not saying the home router
will do nd proxy, unless you consider the mobile attached device to be the
home router itself.

There is no standcardized support for dhcp-pd in 3gpp yet, it is in the
pipe, and deployment will vary. Nd proxy is not a bad solution here.

In the case of 3gpp mobile device, nd proxy is only extending the users's
attached /64 p2p link onto a LAN, it is not sharing with other customers or
provider infrastructure.

Cb
>> Zospf was also closed in v6ops that it’s not possible to use for prefix
delegation in the LAN.   Here is an email to v6ops on closure on ospf for
prefix delegation.

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 24 Oct 2011 09:58:41 -0400

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Friday, October 21, 2011 11:14 PM
> To: Howard, Lee
> Cc: Samita Chakrabarti; [email-masked]
> In message
> <[email-masked]
> le.com>
> "Howard, Lee" writes:
>

The case we were talking about, I think, was a link or device failure.
One expects an outage in those cases.

> for mobility for quite a while but those heavier solution can't be

TCP is not expected to be resilient to outages.  We're not building a
carrier network, we're building a home network.  Bounce the connection.

> web users, hit the stop and the reload.

Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case
of failure.

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2011 10:18:56 -0700

In message <[email-masked]>
 
> One expects an outage in those cases.

If you have two uplinks, you shouldn't need to reboot everything your
house to get connectivity back up because hosts and routers are using
a prefix that is no longer globally routable.

> carrier network, we're building a home network.  Bounce the

No one is suggesting we try to avoid dropping an open TCP connection
on a down transition from the uplink that provided the address the
host is using.

> Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case

Yes.  This is not a TCP ng WG so we don't try to fix TCP here.

There are cases like two uplinks to the same provider (same /64
prefix) that would work without any effort.  This would be rare in the
home though not unthinkable in a home or small business and not
uncommon in medium and large businesses.

We should make it possible for multihoming scenarios such as this to
work, preferably with no configuration, except at the provider.  For
example, an extension to IA_PD essentially saying "use X/65 which came
from X/64 and has no firewall enabled yet" would allow the provider to
do all the configuration needed to make this workable with zero config
on the customer side.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2011 10:38:15 -0700

In message <CAD6AjGQG2p=[email-masked]>
Cameron Byrne writes:
 
> >> Note the IETF IPv6 CE router specifies use of the ULA in the home
> >> to keep the home network independent of the SP network.  This way
> >> my computer at home can still print to the printer even when my SP
> >> IPv6 network is down. We have said this multiple time in v6ops
> >> during development of the IPv6 CE router RFC 6204.
> >
> >
> > Thanks for the reminder.  FWIW, I believe the consensus _is_ for
> > ULAs within the home network, although I do see a few vocal
> > opponents.
> >
> >> I don=92t have the time to read the copious emails of homenet, but
> >> seeing some emails here and there I see homenet regressing on
> >> issues that are closed in the v6ops IPv6 CE router document
> >> development.  Examples of issues homenet is regressing on is ND
> >> Proxy and use of zospf for prefix delegation in the LAN.   There
> >> was only one cell phone vendor who was asking us for ND Proxy with
> >> a single /64 PD delegated to the phone.   We convinced the vendor
> >> at the Prague IETF to abandon that idea because such a /64 would need
> >> RA Proxy in the CE router and RA Proxy is not defined is any RFC.
> I am not arguing for ND proxy, just saying the mobile device may use
> it to extend their connectivity into the house. So I am not saying the
> home route= r will do nd proxy, unless you consider the mobile
> attached device to be the home router itself.
>  
> There is no standcardized support for dhcp-pd in 3gpp yet, it is in
> the pipe, and deployment will vary. Nd proxy is not a bad solution
> here.
>  
> In the case of 3gpp mobile device, nd proxy is only extending the
> users's attached /64 p2p link onto a LAN, it is not sharing with other
> customers or provider infrastructure.
>  
> Cb

The homenet work will have to interoperate with whatever 3GPP has
defined, but does not have to recommend any further use of ND proxy.

The work in homenet might (or might not) affect what 3GPP does in the
future if there is compelling reason to do things differently.

> >> Zospf was also closed in v6ops that it=92s not possible to use for
> >> prefix delegation in the LAN.   Here is an email to v6ops on
> >> closure on ospf for prefix delegation.
> >

I don't think there have been any arguments in favor of using OSPF or
ZOSPF as the address assignment protocol.  There have been arguments
(from me at least) to allow that the assignment protocol take hints
from whatever routing protocol is in place as to which prefixes were
originated from closer uplinks.  This allows the use of a prefered
uplink (ie: wired provider preferred over wireless provider) or a
closest path out to equally preferred providers.

There are also arguments for OSPF as a routing protocol, with
extensions where needed, such as better automated router ID selection.

There are also arguments for as useful a result as possible with zero
configuration as a goal for whatever protocols or usage is defined in
homenet, independent of whether OSPF is in any way involved.

The death of zospf as an address assignment protocol in v6ops does not
negate these points.

Curtis

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Oct 2011 11:33:26 -0700

> Will those arguing for ND Proxy please stand up and be counted?

I have long complained that certain WPAN physical layers should be prepared to attach to home networks, either by application layer gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather than by demanding that every residential network deploy a standard zero configuration prefix delegation and routing protocol to interface to these peculiar WPAN networks.

I know I'm in the minority on this.  I don't think I can point to anyone who agrees with me.  Still, I should be counted.

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

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 24 Oct 2011 11:45:59 -0700

In my v6 ops presentation in Beijing, Dave Thaler agreed with you (James).

I'm on the other side of the argument.

tom

From:  james woodyatt <[email-masked]>
Date:  Mon, 24 Oct 2011 11:33:26 -0700
To:  Ray Bellis <[email-masked]>
Cc:  "[email-masked] Group" <[email-masked]>
Subject:  Re: [homenet] routing requirements

I have long complained that certain WPAN physical layers should be
prepared to attach to home networks, either by application layer gateways
on bastion hosts, or by dedicated ND/RD proxy devices, rather than by
demanding that every residential network deploy a standard zero
configuration prefix delegation and routing protocol to interface to these
peculiar WPAN networks.

I know I'm in the minority on this.  I don't think I can point to anyone
who agrees with me.  Still, I should be counted.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2011 12:38:51 -0700

In message <[email-masked]>
james woodyatt writes:
> prepared to attach to home networks, either by application layer
> gateways on bastion hosts, or by dedicated ND/RD proxy devices, rather
> than by demanding that every residential network deploy a standard
> zero configuration prefix delegation and routing protocol to interface
> to these peculiar WPAN networks.
>  
> I know I'm in the minority on this.  I don't think I can point to
> anyone who agrees with me.  Still, I should be counted.
>  
> --

I'm not sure what you are advocating.  (Except having read ahead I
know whatever it is Dave Thaler agrees with you).

It seems to me like you are advocating treatment of WPAN as a special
case stub with very limited capability appropriate only for a stub.

Is it possible for a WPAN-only connected device to have more than one
reachable device which could provide connectivity to a wired (or WiFi
wireless) network and eventual connectivity to a controlling host?  Is
it also possible that a mesh of WPAN devices could exist?  If so, then
WPAN is no longer a special case stub, it is mearly a low power device
with limited radio coverage and/or limited bandwidth.

For example, a potential application of WPAN is home security.  With
routing each window or door or motion sensor need not be within reach
of the control unit, just within reach of another window or door or
sensor.  This would be a mesh application in the home.  The bluetooth
limitation where the headset has to be near the phone or computer need
not constrain what WPAN is used for in the future.  The effective
range can be extended as long as the device is near *something* that
does WPAN and the something has other connectivity or is part of a
mesh that has other connectivity.

I did mention that devices need to be "bonded" to each other somehow.
These WPAN applications are a case where this is important.  The more
the range of the WPAN is extended, the more you wouldn't want it to be
too easy to spoof the home alarm system or have anything connect to a
given phone or headset.  Of course, limited range is no excuse for the
situation with bluetooth headsets in airports where everything bonds
with everything else because they all use a manufacturer's default.

Curtis

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 24 Oct 2011 21:26:06 -0700

On Fri, Oct 21, 2011 at 17:18, Hemant Singh (shemant) <[email-masked]>wrote:

> closed in the v6ops IPv6 CE router document development.
>

If you haven't read the homenet email conversations, how do you know that
these are regressions?

> delegation in the LAN.   Here is an email to v6ops on closure on ospf for

That email says, basically, "it can't be done" without saying why. We had a
lot of discussion during the interim meeting and we think it can be done
using a routing protocol. Please at least go and read the strawman I posted
to the list.

Prefix delegation has problems with non-trivial topologies or with
multihoming.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 25 Oct 2011 00:12:22 -0500

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 12:26 AM
To: Hemant Singh (shemant)
Cc: Howard, Lee; Samita Chakrabarti; [email-masked]
Subject: Re: [homenet] routing requirements

>If you haven't read the homenet email conversations, how do you know
that these are regressions?

Some regressions are fairly clear from just glancing at the subject of
emails in homenet.  The example is ND Proxy and glancing at emails such
as "cell phone operators may use a single /64" and hence the need for ND
Proxy.  This is precisely what we discussed in v6ops and closed in
v6ops.

>That email says, basically, "it can't be done" without saying why. We
had a lot of discussion during the interim meeting and we think it can
be done using a routing protocol. Please at least go and >read the
strawman I posted to the list.

Cmon, now.  I included clear text showing why it can't be done to v6ops.
My v6ops is open to anyone in v6ops and homenet to reply specifically as
to how one will get around the problems I raised with using any ospf or
routing protocol for prefix delegation.  

multihoming.

Preaching to the choir.  That is why we punted prefix delegation out of
the IPv6 CE router v6ops document.  But using a routing protocol to
figure out prefix delegation for the problems  you describe above
remains to be seen.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 25 Oct 2011 00:14:59 -0500

Sorry typo.  In my email below, please change

"My v6ops" to "My v6ops email"

Hemant

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Tuesday, October 25, 2011 1:12 AM
To: Lorenzo Colitti
Cc: Howard, Lee; Samita Chakrabarti; [email-masked]
Subject: Re: [homenet] routing requirements

 

multihoming.

Thanks,

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 24 Oct 2011 22:22:05 -0700

On Mon, Oct 24, 2011 at 22:12, Hemant Singh (shemant) <[email-masked]>wrote:

> **
> ** **
> emails in homenet.  The example is ND Proxy and glancing at emails such as
> “cell phone operators may use a single /64” and hence the need for ND
> Proxy.  This is precisely what we discussed in v6ops and closed in v6ops.
>

If a cell phone operator gives you a single /64, what do you propose to do?

> using a routing protocol. Please at least go and >read the strawman I
> posted to the list.****
>
> ** **
>
> Cmon, now.  I included clear text showing why it can’t be done to v6ops.
>  My v6ops is open to anyone in v6ops and homenet to reply specifically as to
> how one will get around the problems I raised with using any ospf or routing
> protocol for prefix delegation.
>

Nope, you re-forwarder an email that you wrote saying why you thought it
couldn't be done. You don't say why the strawman architecture I proposed
can't work.

****
> ** **
> Preaching to the choir.  That is why we punted prefix delegation out of the
> IPv6 CE router v6ops document.  But using a routing protocol to figure out
> prefix delegation for the problems  you describe above remains to be seen.
>

Please read the slides I posted and comment.

---

From: Don Sturek <[email-masked]>
Date: Mon, 24 Oct 2011 15:52:08 -0700

I agree with Tom that an application gateway and ND proxy is a non starter
in a home network setting.

Don Sturek

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Oct 2011 09:26:58 +0200

I'd really like to see IPv6 PD solution for the home network for network
stability after a power outage or bringing up a new set of network.

We have gone through similar debate in RPL development timeframe and
finally as far as I know RPL made the prefix configuration optional.

[Pascal Thubert ] Samita, 

I think you are confusing things here. RPL does not delegate prefixes;
never did. If RPL routers that will own different prefixes need to
obtain those prefixes, they will have to do so some other way. What RPL
does is share through an optimized diffusion mechanism the subnet
information between RPL routers that are part of a same subnet. More
like a multilink subnet adaptation of classical RAs.

You'll note that if a router at home needs to establish a tunnel towards
a given gateway to get its traffic routed there, then it can also get a
prefix through DHCP PD from that gateway with RFC 6276. Tunneling can be
useful to direct certain traffic towards certain gateway, and NEMO can
make that simple and secure. In that case, for the purpose of traffic
towards that gateway (eg a utility GW ) the home network is the visited
network.

Cheers,

Pascal

Hemant

---- begin snip ------------

 

Hemant

------ end snip ---------

 

Lee

Hello Howard,

A comment on item 12:

12.  Prefix stability? 

And question to the wg:

 

Thanks,

-Samita

4.      Border detection.  

d.      ISP A is default.

11.  Prevent looping.

12.  Prefix stability?  

Lee

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 25 Oct 2011 13:33:14 -0400

> a prefix that is no longer globally routable.

Agree.  That's different that renumbering or reconverging.

> on a down transition from the uplink that provided the address the

Ah, I thought that's what you were suggesting.
In a scenario where there's a triangle of routers in the home, A to the ISP,
B and C both connected to A, and Host D connected (shared medium) to
both B and C. . . if B fails, how fast must C become available?
I want self-repair within a couple of minutes, but not subsecond.  Or more
precisely, I want self-repair for an arbitrarily large and complex home
network before the user finds the number for tech support.

In another message you said:
> > > Seconds at least.  Goal for providers is 60 msec, but subsecond
> > > would be a reasonable goal for wired.
> > Why would we need that level of repair?  This is a home network, not a
> > carrier network.
> On wired it is easy to get subsecond in a small topology.  It would be nice
> if you streaming audio, movie, phone call to support, etc, stayed up when
> a minor change was made as long as connectivity still existed.

Easy doesn't mean required.
How small a topology?
What about network layers other than Ethernet?
I agree it would be nice, but "nice to have" is different than "required."

> do all the configuration needed to make this workable with zero config

I don't follow you, but it sounds like a good topic for a new thread.

Lee

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Oct 2011 10:47:45 -0700

> If a cell phone operator gives you a single /64, what do you propose to do?

If a certain CableLabs MSO gives each of its several tens of millions of Internet users in North America only a single /64, what do we propose to do?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 25 Oct 2011 10:56:07 -0700

On Tue, Oct 25, 2011 at 10:47, james woodyatt <[email-masked]> wrote:

> If a certain CableLabs MSO gives each of its several tens of millions of
> Internet users in North America only a single /64, what do we propose to do?
>

Admit defeat and either bridge everything or route longer-than-/64 prefixes.
I hope it won't come to that.

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Oct 2011 11:00:48 -0700

On Oct 25, 2011, at 10:56 AM, Lorenzo Colitti wrote:
> 
> Admit defeat and either bridge everything or route longer-than-/64 prefixes. I hope it won't come to that.

I would prefer to deploy NAPT66 rather than route prefixes longer than /64.  In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever the service provider delegates anything longer than /48, so that we can route /48 prefixes uniformly across the entire home network.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 25 Oct 2011 11:03:49 -0700

On Tue, Oct 25, 2011 at 11:00, james woodyatt <[email-masked]> wrote:

> I would prefer to deploy NAPT66 rather than route prefixes longer than /64.
>  In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever
> the service provider delegates anything longer than /48, so that we can
> route /48 prefixes uniformly across the entire home network.
>

Sure, that optimizes routing, but it forces applications to be more complex.
 Do you really want all the STUN / TURN / ICE code that we have today to
keep being necessary?

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Oct 2011 11:07:23 -0700

On Oct 25, 2011, at 11:03 AM, Lorenzo Colitti wrote:

> Sure, that optimizes routing, but it forces applications to be more complex.  Do you really want all the STUN / TURN / ICE code that we have today to keep being necessary?

That's all going to be necessary anyway because of the ubiquitous deployment of RFC 6092 in default-enabled configurations.  Applications are already going to be forced to cope with that complexity, so why not simplify addressing an use NAPT66 on the ULA prefix?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 25 Oct 2011 11:13:04 -0700

On Tue, Oct 25, 2011 at 11:07, james woodyatt <[email-masked]> wrote:

> Sure, that optimizes routing, but it forces applications to be more
> complex.  Do you really want all the STUN / TURN / ICE code that we have
> today to keep being necessary?
>
>
> That's all going to be necessary anyway because of the ubiquitous
> deployment of RFC 6092 in default-enabled configurations.  Applications are
> already going to be forced to cope with that complexity, so why not simplify
> addressing an use NAPT66 on the ULA prefix?
>

Coping with firewalls is easier than coping with NATs, because at least you
know your public IP address.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 25 Oct 2011 13:29:31 -0500

CableLabs will not do so.   Also as I have said in the past to this
mailer that the reason ND Proxy was defeated because an RA Proxy would
also be needed with a single /64.   A Standards Track RFC does not exist
for RA Proxy.   Also, it's not for lack of trying - there are issues
with ND Proxy or a RA Proxy that could not be solved till now.  See
emails Erik Nordmark sent to 6man on ND Proxy in the past year or two.

Also, why ask the question "what if a cellphone operator allocated a /64
to a phone".  I already said, vendors have agreed to use the RFC 3633
PD.   

Cheers,

Hemant

From: [email-masked] [mailto:[email-masked]] On
Behalf Of james woodyatt
Sent: Tuesday, October 25, 2011 1:48 PM
To: [email-masked] Group
Subject: Re: [homenet] routing requirements

	If a cell phone operator gives you a single /64, what do you
propose to do?

If a certain CableLabs MSO gives each of its several tens of millions of
Internet users in North America only a single /64, what do we propose to
do?

--

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Oct 2011 11:34:33 -0700

On Oct 25, 2011, at 11:13 AM, Lorenzo Colitti wrote:
> 
> Coping with firewalls is easier than coping with NATs, because at least you know your public IP address.

Yeah, but you're still going to have to use PCP to acquire explicit maps in the firewall state for your public addresses— because implicit maps alone aren't good enough— and PCP will tell you your external addresses if there is NAPT66 gateway in the loop.  It was expressly designed for support NAPT66, so why not use it for that?

Besides, applications in the IPv4 world are already coping with NAPT44, so adapting to NAPT66 will be a straightforward transition for them.  Wouldn't it be nice for application developers to not have to deal with privacy addressing and multiple provider prefixes and lions and tigers and bears, oh my?  Yes, I realize that means that application content providers with big global data centers won't be able to directly address every little sensor device in every home network on the planet, but I'm actually very mindful that some people consider that a desirable feature of network address translation despite what RFC 4864 says on the subject.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 25 Oct 2011 11:44:25 -0700

On Tue, Oct 25, 2011 at 11:29 AM, Hemant Singh (shemant)
<[email-masked]> wrote:
> CableLabs will not do so.   Also as I have said in the past to this mailer
> that the reason ND Proxy was defeated because an RA Proxy would also be
> needed with a single /64.   A Standards Track RFC does not exist for RA
> Proxy.   Also, it’s not for lack of trying – there are issues with ND Proxy
> or a RA Proxy that could not be solved till now.  See emails Erik Nordmark
> sent to 6man on ND Proxy in the past year or two.
>
>
>
> Also, why ask the question “what if a cellphone operator allocated a /64 to
> a phone”.  I already said, vendors have agreed to use the RFC 3633 PD.
>

http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-08#section-5.3

Expect to see ND Proxy from mobile networks.

I am not saying it is good or bad for HomeNet, i am just saying the
mobile phones will do this... it is homenet's decision how to use it
as access to the mobile network and Internet

Cameron

>
>
> Cheers,
>
>
>
> Hemant
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of james woodyatt

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 25 Oct 2011 12:05:08 -0700

On Tue, Oct 25, 2011 at 11:34, james woodyatt <[email-masked]> wrote:

> Yes, I realize that means that application content providers with big
> global data centers won't be able to directly address every little sensor
> device in every home network on the planet
>

Actually, that's not what it means. It means that you won't be able to
address a device in your own home without paying someone with a datacenter.

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 25 Oct 2011 16:06:40 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, October 25, 2011 2:35 PM
To: [email-masked] Group
Subject: Re: [homenet] routing requirements

Yeah, but you're still going to have to use PCP to acquire explicit maps in the firewall state for your public addresses- because implicit maps alone aren't good enough- and PCP will tell you your external addresses if there is NAPT66 gateway in the loop.  It was expressly designed for support NAPT66, so why not use it for that?

Because it's hard.  Application developers then have to figure out how to use information provided by PCP.

What's hard about privacy addressing?
Does the multiple prefix problem get easier with ULA plus GUA?  Or are you saying we should forget GUA altogether-since one ISP in one place threatens to use /64 by default, nobody can use GUA?
Are lions, tigers and bears significant threats in home networks?

Lee

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Oct 2011 14:06:30 -0700

On Oct 25, 2011, at 1:06 PM, Howard, Lee wrote:

> Because it’s hard.  Application developers then have to figure out how to use information provided by PCP.

They already have to do that for the purpose of maintaining continuity of operations with IPv4 when NAT444 and DS-Lite networks start overtaking the current deployment model of  publicly numbered NAT44 gateways.  They're going to be required to do that for native IPv6 after IPv4 continuity is no longer required, because [AGAIN, I don't understand why nobody seems to get this] CPE gateways are going to be deployed every with IPv6 simple security enabled by default and nobody anywhere will ever reconfigure their gateway into transparent mode.

> What’s hard about privacy addressing?

It means you typically have multiple interface addresses per *prefix*.  A persistent one, e.g. IA_NA, plus zero or one temporary/privacy addresses, e.g. IA_TA, plus zero, one or more *deprecated* temporary/privacy addresses, e.g. from SLAAC.

> Does the multiple prefix problem get easier with ULA plus GUA?

Harder, because now you have multiple global scope prefixes with varying domains of routing.

> Or are you saying we should forget GUA altogether—since one ISP in one place threatens to use /64 by default, nobody can use GUA?

It's not just one ISP.  We have the whole 3GPP ecosystem threatening not to use DHCP6-PD to delegate prefixes shorter than /64 because, hey, 3GPP has a built-in system for delegating 64-bit prefixes.  What reasonable subscriber really needs to ask for anything more than a single /64?

> Are lions, tigers and bears significant threats in home networks?

Metaphorically speaking?

Look, my point here is simple, and it's the same point I was making all those years ago before even the first draft of RFC 6092 was published: all the lovely wonderful mechanisms that RFC 4864 describes for making it so you don't have to use NAT with IPv6 are a huge pain in the neck for application developers.  Without a stateful firewall in the way, all those things RFC 4864 talks about are well worth doing.  However, *with* a stateful firewall in place, they're mostly redundant: the only thing they buy is network layer addressability at the application layer.  Useless in practice without reachability as well.

Alas, RFC 4864 explicitly recommends inserting a firewall.  Which is why we now have RFC 6092 and we will soon have PCP.  And why RFC 6204 explicitly references RFC 6092, and its forthcoming update will cite the PCP specification. And why various procurement documents will be citing both of them as requirements.  Indeed, that was the whole point behind writing RFC 6092 as a template for a requirement specification.  We knew it would be cited like that.  We WANTED that to happen.

I happen to be in the IETF minority who thinks that if we're going to make application developers jump through all the same hoops that NAPT makes them jump through, plus make them put up with a lot of *additional* crazy stuff, i.e. the lions, tigers and bears, which you need because there isn't a NAT providing a unified private address realm, then we shouldn't be surprised that application developers decide that IPv6 is crazy, that we proponents don't know what we're doing, and that they shouldn't want to have anything to do with IPv6 if it can be helped at all.

In my experience, most applications developers look at all those lions, tigers and bears, and they say, "Why is all this stuff even necessary?  Can't we just have one address per interface and use a NAPT like we're already used to doing?"

I'm very sympathetic to them, and at this point, I'm out of convincing reasons to disagree.

Those ubiquitous non-managed default-enabled firewalls everywhere will be enough to force us all to do STUN/TURN/ICE and PCP and all that. I'm not *advocating*, I'm just saying it's how the emerging reality looks to be taking form.  We should just assume it's going to be there, and spec accordingly.

This is where I say, "I told you so," again.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 25 Oct 2011 16:14:57 -0500

Cameron,

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 2:44 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; [email-masked]
Subject: Re: [homenet] routing requirements

>Expect to see ND Proxy from mobile networks.

Thanks much for the reference.  But the reference is still an I-D and
not RFC.  RFC 4389 is on Experimental Track.  One reason this document
could be gated in the IESG or IETF Last Call is by folks saying "you
have asked for ND Proxy" but there is no Standards Track RFC that
specifies an ND Proxy.  My personal belief is to never enforce any
specific tech on anyone.  Let folks use whatever they want to use.
However, we have to see what is technically feasible or not.

Regards,

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 25 Oct 2011 14:24:31 -0700

> not RFC.  RFC 4389 is on Experimental Track.  One reason this document

The status does not matter.  This I-D adds nothing new, it just puts
what's already ratified in the 3GPP and practiced by operators and
implementors into IETF speak.  The I-D is just for your convenience to
understand what is going on in 3GPP and mobile.

CB

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 25 Oct 2011 14:40:20 -0700

>understand what is going on in 3GPP and mobile.

All,

Cameron is noting a very important point.  Draft-ietf-v6ops-3gpp-eps-08 is
a reflection of existing standards work in the 3GPP.  Expect to see real
products using functions based on those standards.  I think (personally)
that it would behoove us to address this.

Given the overall growth of Wireline (Cell) endpoints, it will represent a
non-trivial number of endpoints to consider - IMHO.

Regards,

Victor K

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 26 Oct 2011 11:03:02 -0400

Thank you for expanding your arguments.  I had not heard them before, so I could not understand them.

I'll think about them some more.

Lee

From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, October 25, 2011 5:07 PM
To: [email-masked] Group
Subject: Re: [homenet] routing requirements

Or are you saying we should forget GUA altogether-since one ISP in one place threatens to use /64 by default, nobody can use GUA?

Metaphorically speaking?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Oct 2011 14:36:32 -0400

> I would prefer to deploy NAPT66 rather than route prefixes longer than /64.  In fact, I'm tempted to to say we should prefer to deploy NAPT66 wherever the service provider delegates anything longer…

I would rather have a bridged /64 than a routed, NATted homenet.  In fact, I think it would have to be a /128 before I'd reign myself to NAT.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 27 Oct 2011 09:44:28 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, October 25, 2011 2:37 PM
To: james woodyatt
Cc: [email-masked] Group
Subject: Re: [homenet] routing requirements

>I would rather have a bridged /64 than a routed, NATted homenet.  In fact, I think it would have to be a /128 before I'd reign myself to NAT. 

With a bridge and a tethered cell phone, my PC in the home is served from the Wi-Fi from the cell phone.  I am doing taxes on the laptop and the tax data gets bridged out the cellular network to the SP.   Additionally, I have an AppleTV or some device like that with a Wi-Fi link that is served by the cell phone WiFi.  With bridging, all the video data of the TV in the home gets bridged to the SP.  

Hemant

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Oct 2011 11:13:53 -0400

> With a bridge and a tethered cell phone, my PC in the home is served from the Wi-Fi from the cell phone.  I am doing taxes on the laptop and the tax data gets bridged out the cellular network to th…

You are assuming that the /64 is at the provider.   In that case I agree that it could not work, for the very reason you have given.   In the situation you are describing, the provider has not delegated you a /64; they have merely connected you to their /64.   This is a badly broken configuration: why would anyone do this, particularly for cellular data?

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 27 Oct 2011 08:32:40 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
> >I would rather have a bridged /64 than a routed, NATted homenet.  In
fact, I think it would have to be a /128 before I'd reign myself to NAT.
>
>
>
> With a bridge and a tethered cell phone, my PC in the home is served from
the Wi-Fi from the cell phone.  I am doing taxes on the laptop and the tax
data gets bridged out the cellular network to the SP.   Additionally, I have
an AppleTV or some device like that with a Wi-Fi link that is served by the
cell phone WiFi.  With bridging, all the video data of the TV in the home
gets bridged to the SP.

It sounds like you are implying that the link between your cell phone shares
a broadcast domain with other users like a cable modem.

This is not the case.

The link between the user can the mobile gateway (similar to a cmts or
dslam) is a p2p link that is not shared with any other subscriber.  Bridging
this link will not result in any security changes for you or the level noise
on the link.

In the case of ipv6, your handset has a /64 and your handset is the ONLY
user on that subnet.  Briding that p2p /64 will not result in any new
exposure of your traffic to other subscribers.

Cb

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 27 Oct 2011 10:42:09 -0500

From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, October 27, 2011 11:14 AM
To: Hemant Singh (shemant)
Cc: james woodyatt; [email-masked]
Subject: Re: [homenet] routing requirements

>You are assuming that the /64 is at the provider.  

Yes.   A /64 is shared between the WAN and the LAN segment of the cell
phone.  Such a badly broken addressing was actually suggested to us
authors of the v6ops CE router draft about 2.5 years back by one
cellular phone vendor.

Hemant

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Oct 2011 11:44:09 -0400

On Oct 27, 2011, at 11:42 AM, Hemant Singh (shemant) wrote:
> Yes.   A /64 is shared between the WAN and the LAN segment of the cell phone.  Such a badly broken addressing was actually suggested to us authors of the v6ops CE router draft about 2.5 years back by one cellular phone vendor.

If such a broken configuration were actually deployed, I think it would be fixed quickly, either by not doing it that way, or by installing a really strict egress filter.   It's not in the 3g provider's interests to have this kind of brokenness in a handset.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 27 Oct 2011 11:12:50 -0500

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ted Lemon
Sent: Thursday, October 27, 2011 11:44 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; james woodyatt
Subject: Re: [homenet] routing requirements

>If such a broken configuration were actually deployed, I think it would
be fixed quickly, either by not doing it that way, or by installing a
really strict egress filter.   It's not in the 3g provider's >interests
to have this kind of brokenness in a handset.

As far as I know, no it's not been deployed.  I, Wes Beebee, and Ole
Troan talked to the cell phone vendor (after the Prague IETF) and said
such a /64 deployment should not be deployed and instead DHCPv6 PD as
per RFC 3633 should be used to allocate a shorter than /64 prefix to the
CE device.

Hemant