<skiped> > So looking up the FQDN "www.example.com" may return: > > Identifier MMMM MMMM Locator(s) AAAA AAAA > DDDD DDDD > > Identifier NNNN NNNN Locator(s) AAAA AAAA > DDDD DDDD > > Identifier OOOO OOOO Locator(s) CCCC CCCC > > Identifier PPPP PPPP Locator(s) FFFF FFFF > GGGG GGGG
Hi Robin, Yes, the ILNP DNS SHOULD have worked as what you said. However, it can't do that since there is no direct association between I record and L record, instead, both I record and L record are only associated with a FQDN. By the way, IMHO, maintaining the FQDN->ID mappings and ID->Locator mappings in two separate tables respectively is a better choice from the database design (e.g., table structure and the relationship between tables) perspective. Xiaohu > Each character represents 8 bits. Locators go into the most > significant 64 bits of the IPv6 address and Identifiers go into the > least significant 64 bits. > > In this case, the first two would be hosts in the one physical > network, which is connected to the Net via two ISPs, one of which > provides a PA prefix AAAA AAAA /64 and the other which provides a PA > prefix DDDD DDDD /64 > > The third host, the one with Identifier OOOO OOOO, would be in > another physical network somewhere, which is served by a single ISP, > which provides that network with a PA prefix CCCC CCCC /64. > > The fourth host, with Identifier PPPP PPPP would be in yet another > network somewhere, served by two other ISPs. > > Exactly how ILNP does this, I am not sure. Maybe it doesn't! This > is my understanding of how ILNP could and should work. > > I am pretty sure my naming model diagram for ILNP is correct: > > Role Level Some CEE architectures > such as ILNP > Text name <---- FQDN > Identifier <---- IIII IIII } Combined into > Locator <---- LLLL LLLL } one IPv6 address > > Ideally, Ran would confirm this. > > - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
