Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPv6 Addressing

    2.1 Snapshot Feedback and Problems - RETIRED
    1
    1
    1.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      Rhongomiant
      last edited by

      I have been reading the RFCs for IPv6 addressing and I have stumbled across some IPv6 caveats that we need to consider when creating IPv6 DHCP pools and/or when creating netblocks that are larger than 64bits, actually larger than 70bits. This is not something that has not been discussed, but there is a part that does not make sense to me and I am hoping that someone has some experience that can definitively clear this up.

      The items below effect the 18th digit, the 2nd digit in the 5th hexatet, in an IPv6 address.

      1. The inverted ‘u’ bit, also called the Universal/Local bit, is the 71st binary bit in an IPv6 address. I don't have a question about the 71st bit, but I am posting my understanding in case I have an incorrect understanding.

      This bit indicates whether the address is universally administered, was assigned via stateless autoconfiguration, or is locally administered, assigned manually or via DHCP. Technically 0 means universally administered and 1 means locally administered, but the 71st bit is the inverse of that to make life easier for end users. Therefore, in an IPv6 address if the 71st bit is 0 the address is locally administered and the hexadecimal digit will be 0, 1, 4, 5, 8, 9, C or D and if it is 1 the address is universally administered and the hexadecimal digit will be 2, 3, 6, 7, A, B, E or F.

      1. The ‘u’ bit, also called the Individual/Group bit, is the 72st binary bit in an IPv6 address. This one I do not understand at all, it just does not make sense, so maybe I am having one of the following issues.
      • I have missed an address assignment in the RFCs.

      • I have failed to read between the lines.

      • I lack an understanding in how something works from a networking perspective, but the RFCs assume I have that knowledge and do not spell out the knowledge I lack.

      The primary explanation I have for this bit comes from rfc5375 and I am not seeing anything in other RFCs that provide more information.

      Based on the information I have the, 72nd bit indicates if the address is a unicast address or a multicast address. well, I do not see how that makes sense. I see that anycast addresses exist with-in unicast address space, but not multicast addresses as they all start with FFxx. The only thing I can find is that this may have something to do with MAC addresses. I found the following information, but I can't find anything about reserved MAC addresses? Couldn't a MAC address with a 1 in that position be on a legitimate non-multicast device?

      Ethernet frames with a value of 1 in the least-significant bit of the first octet of the destination address are treated as multicast frames and are flooded to all points on the network. In an Ethernet frame, the least-significant bit of an octet is the first to be transmitted. A multicast is indicated by the first transmitted bit of the destination address being 1.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.