Re: that 4byte ASN you were considering...
At 10:44 10/10/2006, Michael.Dillon@btradianz.com wrote:
- 'Canonical representation of 4-byte AS numbers '
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation...
and what is good or bad about this representation? seems simple to me. and having one notation seems reasonable. what am i missing?
It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token.
Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo "193.0.1." as an IP address. It won't break applications that check if there are exactly 4 numbers in the 0-255 range and 3 dots. The alternative notation (x:y) is much worse in this respect. "x:y" is something (a community string). "x.y" is not.
The real question is what does the notation 1.0 add that the notation 65536 does not provide?
It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number. More important: I think it is a mistake to assume that using AS65536 will NOT break things: 1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS. 2. Just as people having used the regexps that you mentioned, I'm also certain that people have used unsigned short int's or signed long int's in their code. In short, like it or not, you will have to check and update your tools anyway.
If the IETF had really wanted
The IETF process is open and you can still comment on the issue. 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.
Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo "193.0.1." as an IP address.
An application using "[0123456789.]*" will not break when it sees the above typo. 193.0.1. *IS* an IP address-like object and any existing code will likely report it as mistyped IP address or mask.
It won't break applications that check if there are exactly 4 numbers in the 0-255 range and 3 dots.
True, however my point is that I do not believe that all existing applications do this. Therefore, changing their input in an unexpected way will break them.
The real question is what does the notation 1.0 add that the notation 65536 does not provide?
It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number.
In my experience, ISPs do not transmit numbers by phone calls and paper documents. They use emails and web pages which allow cut'n'paste to avoid all transcription errors. And I know of no earthly reason why a general written representation needs to represent the format of bits on the wire. How many people know or care whether their computer is bid-endian or little endian?
1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS.
And how is a special notation superior to if asnum > 65535 then process_big_as else process_little_as In any case, people wishing to treat big asnums differently will need to write new code so the dot notation provides them zero benefit.
2. Just as people having used the regexps that you mentioned, I'm also certain that people have used unsigned short int's or signed long int's in their code.
Typically ISPs are using apps written in higher level languages which are more likely to treat integers as 32-bit signed quantities. In any case, this is a length issue, not an issue of notation.
In short, like it or not, you will have to check and update your tools anyway.
My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools. --Michael Dillon
On Oct 10, 2006, at 4:34 AM, Michael.Dillon@btradianz.com wrote:
Well, it will break an applications that considers everything consisting of numbers and dots to be an IP address/netmask/inverse mask. I don't think many applications do this, as they will then treat the typo "193.0.1." as an IP address.
An application using "[0123456789.]*" will not break when it sees the above typo. 193.0.1. *IS* an IP address-like object and any existing code will likely report it as mistyped IP address or mask.
Actually, most code will parse it as equivalant of 193.0.0.1. Most of the IP address parsers I have encountered will do zero insertion in the middle, such that 10.253 is parsed the same as 10.0.0.253, 10.3.24 is parsed as 10.0.3.24, 192.159.8 is parsed as 192.159.0.8, etc. I'm not saying I think this is necessarily good, but, it is the behavior observed.
The real question is what does the notation 1.0 add that the notation 65536 does not provide?
It is (for me, and I guess most other humans) much easier to read and remember, just as 193.0.1.49 is easier to read and remember than 3238002993. It also reflects that on the wire there are two 16 bit numbers, rather than 1 32-bit number.
In my experience, ISPs do not transmit numbers by phone calls and paper documents. They use emails and web pages which allow cut'n'paste to avoid all transcription errors. And I know of no earthly reason why a general written representation needs to represent the format of bits on the wire. How many people know or care whether their computer is bid-endian or little endian?
Your experience differs from mine. There are lots of situations where ASNs are discussed on telephone calls and/or transcribed to/from yellow stickies, etc. As to matching bits on the wire, no, it's not necessary, but, it is a convenient side-effect.
1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just the next one in the line, it is an AS that will have to be treated differently. The code has to recognize it and replace it by the transistion mechanism AS.
And how is a special notation superior to
if asnum > 65535 then process_big_as else process_little_as
In any case, people wishing to treat big asnums differently will need to write new code so the dot notation provides them zero benefit.
The dot notation is an improvement in human readability. It offers no benefit to machines as they don't care as long as they have a good parser for whatever notation is chosen. The notation is for the human interface.
My point is that if we do NOT introduce a special notation for ASnums greater than 65536, then tools only need to be checked, not updated. If your tool was written by someone who left the company 7 years ago then you might want to do such checking by simply testing it with large as numbers, not by inspecting the code. The dot notation requires that somebody goes in and updates/fixes all these old tools.
So will the colon notation for IPv6 addresses. Owen
participants (3)
-
Henk Uijterwaal -
Michael.Dillon＠btradianz.com -
Owen DeLong