In message <[email protected]> Joel jaeggli writes: > On 10/7/11 12:55 , Curtis Villamizar wrote: > > In message <[email protected]> > > Joel jaeggli writes: > > > >> On 10/4/11 16:17 , james woodyatt wrote: > >>> On Oct 3, 2011, at 9:00 PM, Thomas Herbst wrote: > >>>> > >>>> There will be wide area network providers who interwork with the > >>>> home network but do not provide global connectivity. Two mentioned > >>>> so far are utility networks and 3g providers. One of the outputs > >>>> of the wg should be to define how they should be configured to > >>>> perform their role without messing up Internet communication. > >>> > >>> Those utility networks have a fundamental problem that I contend is > >>> beyond the scope and charter of HOMENET. > >> > >> every-time I connect my split-tunneled vpn to my home network, I am > >> attaching a non-dfz-connected inter-network behind my home network, I > >> don't think of this as rare or particularly exceptional problem (it's > >> not confined to utility networks). it does have the potential for > >> address collisions (as built currently)in ipv4 due to the extensive if > >> not quite complete use of rfc-1918 used within the scope of that private > >> internetwork. > > > > > > Joel, > > > > Being new to this WG I may have it wrong, but a point of this WG may > > be to change the use of RFC1918 space to IPv6 space. > > I've got a little experience numbering networks...
Yes I know. > My observation which apparently you missed was in response to James > Woodyatt's point about whether the interconnection of private > inter-networks (e.g. those without internet routes for example a utility > such as an elecritc provider) was is scope for homenet. So why would the elecritc provider not support IPv6 if they wanted to use the same internet infrastructure provided by the homenet? The model today is the the meter contacts the elecritc provider (this works with NAT). With IPv6, the electric provider could poll the meters, as long as they know the meter's IPv6 address. If anything, the meter could push a new IPv6 address on installation and each time it saw a new address assigned to it (as is done in mobility applications, but this should not be often for a stationary meter). Of course some reasonable authentication is needed. The point is that once IPv6 is supported, everything has a global address, things like this are easier (either end can initiate interaction). The example of electric meters is a trivial one but the same can apply to other things. The example of checking a thermostat or other thing in the home from a mobile phone is a better example of a need to initiate interaction from outside the homenet, where global address space is helpful. Others uses where having a global IPv6 address are nice are the home KDC, plus CVS, SVN, or GIT server, etc. These may not be common in the average home. :-) So the answer may be it is out of scope if the utility has some hack over some private infrastructre like IP over the power lines that is not connected to the homenet, in scope if they are using global addressing and taking advantage of the homenet. Maybe water meter or gas meter would be better examples since I don't know of IP over water pipes. In a lot of places these meters use a twisted pait that goes who knows where and might be better served with a WiFi chip or low power WPAN or plain ol' Ethernet and using the homenet. It may be possible to work something out with the local provider (MSO or ILEC) if the homeowner takes down their Internet access or doesn't want Internet. For example, leave the wires and local provider low end router in place, but with filters (where they can't be tampered with) only allowing access to the meters. IMHO: these sort of arrangements are well out of scope. The homenet is just a connection to the global Internet. IMO: The homenet equipment needs to be prepared for an IPv4 only provider. a native IPv6 only provider, or a dual stack provider. For IPv4, expect to most often get one address from the provider for local use (via DHCP) and enable NAT by default, or have multiple addresses configured (and optionally also have NAT configured). With IPv6, expect to get more than will ever be needed (a /64). Note that you *can* subdivide a /64 in a homenet as long as any advertisement to the provider (globally routable prefix) is /64 or shorter. [I'm using /112 and /96 (each on 2 byte boundaries) within a /64 and it works fine]. If there is no native IPv6, the homenet equipment must support a configured 6to4 tunnel or other configured tunnel. Whether to automatically bring up a 6to4 tunnel in the absense of native IPv6 and the absense of configuration, is an issue worth discussing. I think no, since it may overload 6to4 servers, but I'm willing to be persuaded. > > For example, not > > only your computers, but your home thermostats, your electic meter, > > your entertainment systems, SIP phones, etc can each have global IPv6 > > addresses. Beats "go check the thermostat at 10.0.0.1" from your > > mobile phone. Authentication will be an issue for product (but > > from the charter, not in scope for the WG). > > > > With an IPv6 only home network you don't need to use rfc1918 number > > space. You can put your /64 behind a firewall if you like. You can > > use RFC3142 as one means to reach the IPv4 world at least for anything > > based on TCP (SMTP, HTTP, etc). Or you can use application gateways > > (what I use). The benefit over using net 10/8 or other rfc1918 space > > is that if your hosts at different sites use IPv6 and if your laptop > > in a IPv4 only site can at least get a 6to4 tunnel, you can use a > > globally routable IPv6 number space. > > > > Try using IPv6 instead of rfc1918. (for example, see mail headers). > > > > If the provider side of the WAN connection just hands the home router > > an IPv6 prefix, then some form of autoconfiguration is possible. If > > not, IPv4 rfc1918 autoconfiguration can be used with NAT unless a > > tunnel is configured. It wouldn't hurt to do both IPv4 rfc1918 > > autoconfiguration with NAT and IPv6 autoconfiguration with a native > > prefix or with a configured tunnel (or with 6to4 enabled). > > > > Curtis Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
