> Yup. Are you aware of similar issues with changing the IAID? If the ISP > has a > limit to how many prefixes can be assigned on a particular customer port, > that could cause issues, but if it's a supported feature as it would be in > Mikael's case, I think it should be OK. Do you know the details of what was > causing the issue?
I don't remember the details. I looked at BBF TR-124, to see if there was something similar there, and there wasn't. Then I looked at eRouter specs, and did see that they are specifically re-iterating the requirement for persistence. So maybe it came from the cable companies. Which could explain why my memory of details is so fuzzy. As for IAID, TR-124 says: "The RG IAID value in DHCPv4 and DHCPv6 MUST be a 32 bit number encoded in network byte order. In cases where the RG is functioning with a single DHCP client identity, it MUST use value 1 for IAID for all DHCP interactions. IAID is defined in IETF RFC 3315. In cases where the RG is functioning with multiple DHCP client identities, the values of IAID have to start at 1 for the first identity and be incremented for each subsequent identity. The RG's mapping of IAID to its physical aspects or logical configuration SHOULD be as non-volatile as possible. For example, the RG MAY use IAID value 1 for the first physical interface and value 2 for the second. Alternatively, the RG MAY use IAID value 1 for the virtual circuit corresponding to the first connection object in the data model and value 2 for the second connection object in the data model." The TR-124 requirements are used by DSL providers for the CE routers they procure/provide, and aren't expected to apply to "retail" CE routers. The fact that this IAID requirement didn't make it into RFC 7084 leads me to believe that the behavior of retail CE routers wrt IAID is a "don't care". Barbara _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
