>> If a node is assigning prefixes smaller than /64 (or /24 in IPv4), how >> does it prevent fragmentation of the available space?
> IIRC that is defined in the prefix assignment draft. Right. Smart draft. >> ### Prefix Domain is not clear [...] > The prefix domain TLV is used to convey some meta-information about prefixes. [...] > There are several use cases here: So it's essentially a vendor extension encoded as either an IP or a domain name? >> ### Unknown DHCP options in DELEGATED-PREFIX cause prefix assignment to fail > So unknown top-level options are simply forwarded. I'm still confused. If I'm not doing PD, am I not allowed to grab prefixes in a delegated prefix with unknown options? What should an implementation that doesn't speak DHCP do -- not even parse the DELEGATED-PREFIX sub-TLVs (which is what I do currently), or drop any delegated prefixes with any DHCP options at all? (I'm actually parsing DHCP, but only the name server bits.) >> ### Domain name has no priority > I suppose since we have a default value we might want to add that this MUST > NOT be sent unless explicitly configured. I'd still like a priority field. It doesn't seem like it would add much implementation complexity. >> ### NODE-ADDRESS is underspecified > The draft says: > "An assigned address MUST be in the first quarter of an assigned > prefix currently applied on a Common Link which includes the > interface specified by the endpoint identifier." So in order to put a /128 on the loopback I need to do the full prefix assignment dance. Please don't change that, I'll let you know how I feel about it when I'm finished implementing PA. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
