Subject: ip6.arpa: bit-string labels with prefix lengths not on 4 bit boundaries

From: Peter Bieringer <[email-masked]>
Date: Tue, 19 Feb 2002 22:44:03 +0100

Hi,

during implementing bit-string label support in "ipv6calc" I run (for
me) into a problem and found no example.

Every example shows prefix lengths in 4 bit boundaries :-(

Printing prefices:

1) "Standard":
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/64
-> \[x3ffeffff01234567/64]

2) Now what about:
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/63
-> \[x3ffeffff01234566/63]   ?

or
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/65
-> \[x3ffeffff012345678/65]   ?

Is this ok, keeping most significant bits aligned?

Printing suffices:

3) "Standard":
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/64
-> \[x89abcdef00112233/64]

4) Now what about:
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/63
-> \[x189abcdef00112233/65]   ?

or
3ffe:ffff:0123:4567:89ab:cdef:0011:2233/65
-> \[x09abcdef00112233/63]

Is this ok, keeping now least significant bits aligned?

If both to "yes", this isn't a unique representation because who
decides when to use which bits.

Major question:
from which position are the bits are counted and displayed aligned?

From the left one or from the right one?

Has anyone a definition or examples available?

Looks like either suffices or prefixes have to be shifted bitwise in
displaying resulting in not easy recogniced values afterwards.

RFC 2874 doesn't really help me, perhaps because of my less English
knowlegde...

        Peter

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: David Terrell <[email-masked]>
Date: Wed, 20 Feb 2002 00:05:27 -0800

> me) into a problem and found no example.

Save your energy, bit-strings are being deprecated in the ip6.arpa tree.

-- 
David Terrell            | Q. Is C an acronym? 
[email-masked]             | A. Yes, it stands for ``C''. It's another
Nebcorp Prime Minister   |    of those funky recursive acronyms.
http://wwn.nebcorp.com/  |  - "Infrequently asked questions in comp.lang.c"
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Peter Bieringer <[email-masked]>
Date: Wed, 20 Feb 2002 09:16:10 +0100

--On Wednesday, February 20, 2002 12:05:27 AM -0800 David Terrell
<[email-masked]> wrote:

>> during implementing bit-string label support in "ipv6calc" I run
>> (for me) into a problem and found no example.
> 

Is this an official statement? Who tell this all very modern
resolvers...

BTW: looks like the same problem occurs in the forward chaining using
A6.

        Peter

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Feb 2002 11:26:21 +0200 (EET)

> Is this an official statement? Who tell this all very modern

There are no official statements, but you may want to look at:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-00.txt

or minutes from Dnsext/ngtrans joing meeting in IETF51 in London.

No resolvers as such (used by default in operating systems) that I know of
implement A6/DNAME; BIND9 lwres and friends are the only ones I think.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Feb 2002 16:30:24 +0700

Date:        Wed, 20 Feb 2002 09:16:10 +0100
    From:        Peter Bieringer <[email-masked]>
    Message-ID:  <44900000.1014192970@localhost>

  | BTW: looks like the same problem occurs in the forward chaining using
  | A6.

I'm not sure if there's a problem with alignment in bitstring (problem
meaning perhaps unusual values needing to be generated), but there isn't
in A6 - the address part of an A6 is always the least significant N
(128 - prefix len field of A6 record) bits of the address, and the least
significant bit of that is always the least significant possible bit
of the value - so the alignment used in the A6 record, and the natural
alignment of the address are always the same (ie: some bits may be
cleared, or ignored, but they're never shifted around).

kre

---

From: Peter Bieringer <[email-masked]>
Date: Wed, 20 Feb 2002 21:17:47 +0100

--On Wednesday, February 20, 2002 04:30:24 PM +0700 Robert Elz
<[email-masked]> wrote:

>   | BTW: looks like the same problem occurs in the forward chaining
> using   | A6.

> but there isn't in A6 - the address part of an A6 is always the
> least significant N (128 - prefix len field of A6 record) bits of
> the address, and the least significant bit of that is always the
> least significant possible bit of the value - so the alignment used
> in the A6 record, and the natural alignment of the address are
> always the same (ie: some bits may be cleared, or ignored, but
> they're never shifted around).

Right indeed, but which wins?

Let's assume following

Correct setup (example from BIND ARM):

$ORIGIN example.com.
host    IN A6 64 0:0:0:0:42::1 company.example1.net.

$ORIGIN example1.net.
company IN A6 0  3ffe:8050:201:1860::

Resulting address 3ffe:8050:201:1860:42::1

Buggy setup:

$ORIGIN example.com.
host    IN A6 64 0:0:0:0:42::1 company.example1.net.

$ORIGIN example1.net.
company IN A6 0  3ffe:8050:201:1860:8000::

Resulting address 3ffe:8050:201:1860:8042::1 ?
        or
Resulting address 3ffe:8050:201:1860:0042::1 ?

Which one is ok?

        Peter

---

From: [email-masked]
Date: Thu, 21 Feb 2002 10:34:18 +1100

> Resulting address 3ffe:8050:201:1860:0042::1 ?

	3ffe:8050:201:1860:0042::1

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------