Re: Modifications to the inet6num in the RIPE Database
Joao, sorry for the late comment, but I have a small issue with the following:
Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48
I think the separation between TLA and NLA space is not that clear. There are eight reserved bits between the TLA field and the NLA field (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). By introducing the checks as you proposed, you seem to have decided that those should be part of the NLA field. I don't think this is warranted. Section 3.2 of RFC 2374 makes it clear that some of the reserved bits might also be used to extend the TLA field in the future. You should permit either both TLAs and NLAs, or neither of them for prefix lengths between 16 and 24. I suggest rejecting such prefixes for the moment, and keep in mind that the reserved bits may be added to the TLA and/or NLA over time. If I missed some change in the intended structure of IPv6 unicast addresses, please apologize. Regards, -- Simon Leinen simon@switch.ch SWITCH http://www.switch.ch/ Who is General Failure & why's he reading my disk?
Hi Simon, thanks for your comments. You are absolutely right. Actually I would even add to your comments by saying that inet6num objects should be rejected if the prefix is in the reserved field except if the TLA is the one reserved for sub-TLAs (0x0001). In that case the status field should have the sub-TLA value if the prefix is 16<l<27. Is that OK with everyone? Regards, Joao Simon Leinen <simon@limmat.switch.ch> writes: * Joao, * * sorry for the late comment, but I have a small issue with the * following: * * > Syntax checks will be done so that: * > TLA is only allowed if the prefix length is 3<x<=16 * > NLA is only allowed if the prefix length is 16<x<=48 * * I think the separation between TLA and NLA space is not that clear. * There are eight reserved bits between the TLA field and the NLA field * (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). * * By introducing the checks as you proposed, you seem to have decided * that those should be part of the NLA field. I don't think this is * warranted. Section 3.2 of RFC 2374 makes it clear that some of the * reserved bits might also be used to extend the TLA field in the future. * * You should permit either both TLAs and NLAs, or neither of them for * prefix lengths between 16 and 24. I suggest rejecting such prefixes * for the moment, and keep in mind that the reserved bits may be added * to the TLA and/or NLA over time. * * If I missed some change in the intended structure of IPv6 unicast * addresses, please apologize. * * Regards, * -- * Simon Leinen simon@switch.ch * SWITCH http://www.switch.ch/ * * Who is General Failure & why's he reading my disk? *
participants (2)
-
Joao Luis Silva Damas
-
Simon Leinen