On 8 jan 2008, at 17:44, Bound, Jim wrote:
Now obviously it's possible to argue that this isn't a good way of filtering (in both directions, it can be too much or too little), but since that is what you get with pretty much any current CPE those discussions are largely moot. The only changes that are possible are those that BOTH improve security AND usability at the same time. Any change that improves one over the other will be seen as unacceptable by one camp.
The above is key per Fred's call to action that started this thread and to determine what we in the IETF can provide to support the Alain new social contract do we only consider today or do we think out of the box a bit too? Also I dc not believe the IETF can provide a deployment exact case for the new social contract that the market must decide and then implement all we can do is provide the ops tools or possibly new protocol work to assist it in the IETF. We need to keep our scope correct and responsibility within the IETF for what we do as an SDO correct.
The way I see it, we pretty much have all the protocols that we need. We probably need one or two additional ones, but at this stage, new protocols should be the exception rather than the rule. What we're missing is a deployment model, which is something close to Alain's social contract. With IPv4, CPE vendors have a fairly good handle on what to expect from ISPs, and ISPs know what to expect from their customer's hosts and CPEs. With IPv6, that's not the case, and the fact that we expect more than a single address to be given out to a customer and we have several ways to provision these addresses defined make this more complicated than with IPv4.
I'm pretty sure the IETF doesn't have all the answers here, but I don't see any other organization stepping in, so I guess we'll have to come up with something. Obviously that must be something that makes sense in the grand scheme of IETF/IPv6 things, and it must be something that the vendors that come to the IETF support. That's the part we can do in v6ops for the most part. But we also need ISPs and probably organizations like the DSL Forum to come on board. I'm not 100% how we can accomplish that, but I think it will help if we can at least agree on a good number of issues here. A wide range of viewpoints is represented within the IETF, so rough consensus here probably means that we have something fairly solid.
Transition
Again we cannot force this but a phenomena for IPv6 that needs to change is that the provider needs to provide dual-stacked services not just IPv4 or IPv6 native only. The question is do we in v6ops assume the provider provides dual stack services as an assumption for the work threads Fred suggested?
There is a difference between dual stack services and dual stack network access. (Hopefully improved) NAT-PT does the former but not the latter. I'd say we should probably not assume dual stack from the ISP because being able to support a single stack model makes the solution stronger.
3. Should a host have the option of signalling to a CPE that it doesn't require any filtering?
Absolutely yes or as I state above permit IPsec to pass through.
It seems we have yet to reach consensus, rough or otherwise, on this point...
4. Is implementing DHCPv6 snooping and option insertion, similar to what currently happens with DHCP for IPv4, a good option for vendors of broadband equipment, or is a provisioning solution where this isn't necessary preferable?
I am not parsing entirely why this is a valid question for CPE edge, but can see it as server in the home? But, for the home environment I strongly suggest that stateless IPv6 be used so can you re-phrase the question at least for me? Thanks.
With IPv4 broadband aggregation equipment snoops DHCP and inserts an option that holds some kind of port identifier. Obviously something very similar can be done for DHCPv6, but if this is hard to implement, it may be useful to consider alternatives.
7. Is the model where there is a CPE with modem functionality but not router functionality a reasonable one?
I don't think so and this should be transparent to v6ops mission for this thread is my input.
Reason for the question: if ISPs insist on CPEs with modem and router functionality integrated, we can skip some issues (RAs from ISP to customer) but that means the ISP - CPE interface becomes more important because if it doesn't work right the user is left without recourse.
9. If 8, then what is the value of the M and O bits?
These would only be valid for CPE devices if DHCPv6 prefix delegation is used and though I think that will happen we should not assume this as the default but cover both. I won't respond here on the M and O context or indirection as that could be huge rat hole at this point.
If we don't address the M/O issue this means the CPE will have to initiate DHCPv6 prefix delegation always.
12. How do we avoid problems caused by customer equipment MAC addresses clashing with that of other customers?
I really hope we don't have to work on this in v6ops or in the IETF this is a standard problem regardless of IPv6 or IPv4? Or am I missing the specific IPv6 issue? Thanks.
It's not our issue, but it's something that could impact what we can and can't do. For instance, "link layer NAT" that was mentioned as a solution to this issue requires an ND ALG.
13. How many devices are allowed to connect to a CPE(m)?
Absolutely none of the IETF's business. Sorry this is a product feature set for the vendors.
It's more an ISP issue. If ISPs want this to be exactly one, vendors can build in logic that avoids problems when a user tries to connect multiple devices anyway.
14. What kind of addressing is used between the ISP and the first CPE(r)? Global customer specific, global shared between customers, link local only?
Again all will be used we need to define what the technical details are for each case if we want to take on that much work.
I don't think anyone has a pressing need for this to be any particular way, they just want things to work. If we can recommend an optimal choice, that makes life simpler for everyone.
15. How does DAD work on the subnet between an ISP and customers? Should hosts and CPEs ignore their own DAD packets when they loop back to them?
No one ignores DAD that is required to use DAD per the specs.
I think the spec is unclear here. If I send a DAD ND packet out for my IPv6 address and I then receive such a packet also for my address, but it turns out that this was a copy of my own packet that looped back in a way that isn't obvious locally, then assuming the address is in use by someone else is not a good idea, because that limits layer 2 topologies for no good reason. A simple check to see whether the source MAC address is the local MAC address can solve this.
DNS
16. How do we expect customer devices to enter into the DNS?
As they do today.
Today ISPs often just give a name to every address. If you get that address, you get the name that goes with it. However, in IPv6 you can't populate a /32 with 2^96 DNS names so this will have to happen in some other way.
19. How do users authorize third-party devices (ranging from gas meters to set top boxes) use of their broadband connection?
Sorry not the IETF's business.
True. But the answer is important for us: if it's "put them in a separate subnet" this means the CPE model must support multiple subnets.