North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: that 4byte ASN you were considering...

  • From: Owen DeLong
  • Date: Tue Oct 10 12:02:37 2006

On Oct 10, 2006, at 4:34 AM, [email protected] 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

Attachment: PGP.sig
Description: This is a digitally signed message part