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. -- james woodyatt <j...@apple.com> member of technical staff, core os networking
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
