On Fri, 10 Sep 2010, Jari Arkko wrote:
Host support is important because that is an area where neither the IETF, any single vendor, or the DSL operators have any easy way to change the situation. But it is of course by no means the only constraint. The operators have their issues as well. Even though they are in control of their own networks, they probably want to keep their underlying L2 network architecture as it is, despite introduction of IPv6 or other new features.
Reading draft-krishnan-6man-rs-mark-06.txt I read this as an "dhcp option 82"-analogy in the IPv6 SLAAC world. Please correct me if I'm wrong.
We are using the deployment model where this is applicable, and the concept seems like it makes sense for using SLAAC in this deployment model (I wouldn't really want to, but it might be nice in case of lack of DHCPv6 support in end nodes).
Some questions though, on the interface on the edge router towards the access node (which will receive the tunneled RS packet), it seems there should be a recommendation for the edge router to not accept untunneled RS, or at least a recommendation that a knob for this behaviour should exist? If the interface is only used for customer traffic then there should never be an untunneled RS packet if the access node is correctly configured?
Also, in 5.1 perhaps there could be a clarification that the new packet is still a RS packet, it took me a few readings before I understood that part? (did I understand it correctly?) I'm still uncertain, there is text about "tunneled packet" and I was looking for the layout of this packet, and then I deduced that it's probably RS packet with added option header?
I like that the fields are TLV, makes for easy extension in the future. Should perhaps the "option length" be more than 0-255, perhaps 16 bits instead of 8?
Has the SAVI WG been involved or seen this draft before? I can see some recommendations that they need to implement as well, such as disallowing LIO packets from the end customers (drop on floor or replace), rate limiting the RS packets per second from the end users, etc.
-- Mikael Abrahamsson email: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
