On 29-Nov-2006, at 08:30, Henk Uijterwaal wrote:

[EMAIL PROTECTED] wrote:

On the NANOG list it has already been pointed out that a lot
of network management software cannot handle such notation and
in some cases, 1.0 could be interpreted as the IP address 1.0.0.0. It has been confirmed that one widely used PERL library interprets x.y as IP address x.0.0.y.

I think this is a bug.

If it is, it's a very long-standing one. For example, see INET(3) which I think is of 4.2BSD vintage, and which appears to have similar semantics to the mentioned perl library:

INTERNET ADDRESSES
Values specified using the `.' notation take one of the following forms:

           a.b.c.d
           a.b.c
           a.b
           a

When four parts are specified, each is interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. Note that when an Internet address is viewed as a 32-bit integer quantity on the VAX the bytes referred to above appear as ``d.c.b.a''. That is,
     VAX bytes are ordered from right to left.

When a three part address is specified, the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address. This makes the three part address format convenient for speci-
     fying Class B network addresses as ``128.net.host''.

When a two part address is supplied, the last part is interpreted as a 24-bit quantity and placed in the right most three bytes of the network address. This makes the two part address format convenient for specify-
     ing Class A network addresses as ``net.host''.

When only one part is given, the value is stored directly in the network
     address without any byte rearrangement.

Because of this I think it would be useful for the IETF
to publish a draft defining the notation for AS numbers
so that we can either keep it simple or, if a new notation
is to be used, then publicly state the issues of software which needs to be changed. Such a draft should really come
from the WG which extended the AS number in the first place.

There is:

  Canonical Textual Representation of 4-byte AS Numbers
  draft-michaelson-4byte-as-representation-02

describing the format of ASN32 and

The draft above received significant operator criticism.

The consensus I saw on NANOGm, for example, was that there was (a) no useful reason to be able to distinguish between a 16-bit AS number and a 32-bit AS number less than 65536, (b) no good reason to use punctuation to separate the most- and least-significant 16 bits of the 32-bit ASN, and (c) every reason to think that the most sensible representation was just "bigger decimal numbers".


Joe


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Reply via email to