In message <CAD6AjGQG2p=v+0z3x6ab+ggw1bo2dizp6ztvik3b7uo-o95...@mail.gmail.com> Cameron Byrne writes: > On Oct 24, 2011 1:24 AM, "Ray Bellis" <ray.bel...@nominet.org.uk> wrote: > > > > > > 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=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. > >> 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 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. > > > > Again, thanks, that's useful background. > > > > Ray 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 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
