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:lore...@google.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 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: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 5:26 PM To: Samita Chakrabarti; homenet@ietf.org 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 From: Samita Chakrabarti [mailto:samita.chakraba...@ericsson.com] Sent: Friday, October 21, 2011 5:08 PM To: Howard, Lee; homenet@ietf.org Subject: RE: routing requirements 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: 8. Support for multiple upstream networks is a requirement. 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: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Howard, Lee Sent: Friday, October 21, 2011 11:32 AM To: homenet@ietf.org 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. 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.
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
