Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me. Also, contrary to IPv4 and IPv6, we are very likely to have a mixed ASN16 and ASN32 world "forever". In fact, the ASN32 standard is specifically designed with this in mind, and the two worlds can live happily together. So, any tool will have to be upgraded sooner or later, the only question is when and how. In both cases (change existing attributes or create new ones), people will have to upgrade when they move into the ASN32 world. The difference is in the code change. In my draft, the tools will have to recognize 2 versions for an AS. Changing attributes means that tools will have to check if the ASN16 or ASN32 version is there, then parse that to get the information. In the end, this doesn't look like a big difference to me. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000.