CCNP cisco press book 642-902 and IPV6 section

obelix2obelix2 Posts: 2Registered Users ■□□□□□□□□□
Anyone know why on page 551 of the 642-902 book, they say the local block is FD00::\8. If you go to IANA, and read the RFC 4193 here (RFC 4193 - Unique Local IPv6 Unicast Addresses), section 3.1 and section 8, or even on the main iana page for IPV6 assignments, say that the block is FC00::\7 (which encompases FD00::\8, but doesn't begin there).

Thanks

Comments

  • CiscoCertsCiscoCerts Posts: 112Member
    FWTW I've checked the errata and it isn't listed:
    http://www.ciscopress.com/content/images/9781587202537/Errata/9781587202537Errata12_31_11.doc

    From what I understand FC00::/7 is the reserved block, but FC00::/8 is undefined. The unique local addresses in use will use FD00::/8, which is probably why the book listed it that way.

    Wikipedia has a good article on it: Unique local address - Wikipedia, the free encyclopedia
  • obelix2obelix2 Posts: 2Registered Users ■□□□□□□□□□
    I read the wikipedia link you sent, i find it interesting they quote IETF as not quite excepting the FC00::\8 block. I went the reference page they had listed beside that statement, but didn't quite support that statement. I guess everyone wants to be using global, but this is certainly something that should be cleared up, because if IANA and the RFC say to use FC00::\7, and IETF say use FD00::\8, that could be quite confusing. Guess its best to stay away from FC::\8 until it's cleared up.
  • SubnetZeroSubnetZero Posts: 124Member
    obelix2 wrote: »
    Anyone know why on page 551 of the 642-902 book, they say the local block is FD00::\8. If you go to IANA, and read the RFC 4193 here (RFC 4193 - Unique Local IPv6 Unicast Addresses), section 3.1 and section 8, or even on the main iana page for IPV6 assignments, say that the block is FC00::\7 (which encompases FD00::\8, but doesn't begin there).

    Thanks

    Historically RFC 1884 reserved the block FEC0::/10 for site local address but this has since been deprecated and replaced with FC00::/7 for used in private networks as defined in RFC 4193.

    The reason the /7 was broken up into two /8's was so you could have a choice. The idea is that anything in the FC00::/8 would have the 40 bit global-id allocated and controlled by a trusted third party (registrar). On the flipside you can also use the FD00::/8 and you can generate your own global-id.

    To be honest I don't know what the final result was but this was the original intent.

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced
    :cool:
  • SubnetZeroSubnetZero Posts: 124Member
    I finally went back and reread that portion of the RFC and you're right, it never talks about the two being broken up into two /8's. Strange!

    However was doing some more research and here is what I found from the IETF which should be correct??

    There are two ways to allocate Global IDs. These are centrally by a allocation authority and locally by the site. The Global ID is split into two parts for each type of allocation. The prefixes for each type are:

    FC00::/8 Centrally assigned
    FD00::/8 Locally assigned

    Each results in a 40-bit space to allocate.

    Two assignment methods are included because they have different properties. The centrally assigned global IDs are uniquely assigned. The local assignments are self generated and do not need any central coordination or assignment, but have a lower (but still adequate) probability of being unique. It is expected that large managed sites will prefer central assignments and small or disconnected sites will prefer local assignments. It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication, initially or as a future possibility, use a centrally assigned prefix as there is no possibility of assignment conflicts. Sites are free to choose either approach.

    This document only allocates the prefix (FC00::/8 for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document.


    I'm not sure what to believe now since RFC 4193 paints a different picture, but this is how I was taught.

    While no trees were harmed in the transmission of this message, several electrons were severely inconvenienced
    :cool:
Sign In or Register to comment.