Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

[james woodyatt <[e-mail]>]

On Feb 21, 2017, at 16:41, STARK, BARBARA H <[e-mail]> wrote:
> 
> Sorry, James, I disagree.
> The charter of v6ops is still doing things that help get IPv6 rolled out. Which is exactly what these ISPs are asking for help with. Which has nothing to do with multi-router home network topologies.
>  
> I believe a very targeted document to meet the needs of these ISPs is what we should be aiming for.

Hi Barbara,

Please let me explain why that posture actually makes the roll out of IPv6 more difficult rather than less difficult. Consider the case of Thread™ border routers, which I am involved in the process of defining the best practices for implementation in the Thread Group.

    <https://www.threadgroup.org/Portals/0/documents/whitepapers/Thread%20Border%20Router%20white%20paper_v2_public.pdf <https://www.threadgroup.org/Portals/0/documents/whitepapers/Thread%20Border%20Router%20white%20paper_v2_public.pdf>>

The networks behind these border routers are IPv6-only. They are 6LoWPAN mesh networks. They are typically implemented in devices that join home LAN segments with Wi-Fi™.

If IETF updates RFC 7084 without including a strong recommendation to provide HNCP services on the LAN interfaces, it will serve as a very strong signal to groups like Thread™, which are currently working on such border routers, that IETF does not believe routers serving residential subnets should be provisioned with sufficient address space to support downstream routers, like Thread™ border routers.

That’s a big deal. It will have serious consequences.

People working on this stuff here at Google currently observe in the wild IPv6 home gateways, presumably RFC 7084 ones, that do not respond positively to DHCP-PD requests, either because they do not receive delegations of more space than a single /64 from service providers, or they do not have sufficient remaining space to respond positively to DHCP-PD requests because all the prefix space has been consumed by other clients.

So, how does one imagine such border routers will make hosts on those IPv6-only links behind them reachable via the public IPv6 Internet? There are several alternatives available in the event that RFC 7084 is updated without a recommendation to implement HNCP. Here are some ideas that I’m seeing my colleagues— experts in the field— seriously promote as things that SHOULD be done in that event:

1. Use NAT66 (not NPTv6, NAT66 with address and port translation) to masquerade the entire mesh behind the border router as the same IPv6 host on the home LAN segment (my hunch is this is the most likely alternative to be implemented, not the least, and for reasons that are very difficult to counter).

2. Use ND Proxy to masquerade the entire mesh behind the border router as the same Wi-Fi MAC address (this has problems related to interoperability with various Wi-Fi implementations, and it makes some people I know nervous, hence the attraction to NAT66 which trades those problems for more familiar problems already well understood in the IPv4 world).

3. Use NAT64+DNS64 to masquerade the entire mesh behind the border router as the same IPv4 host on the home LAN and just forget entirely about IPv6 (this is a required capability for dealing with IPv4-only service providers, which do still exist, sadly, and the idea we are considering here is to just never bother doing more than NAT64+DNS64 and therefore hope the whole IPv6 on the public Internet just blows over).

I don’t know about the rest of the V6OPS working group, but I think all three of these alternatives are terrible for everyone. Hence, it would be better if RFC 7084 is updated to include a strong recommendation to implement the HOMENET protocols. Just my 0.02 euros, your mileage may vary, offer not valid in the Bear Flag Republic.

Barbara, and anyone else taking a similar view, please please please reconsider your position.


--james woodyatt <[e-mail] <mailto:[e-mail]>>