Short version: Name Based Sockets can only be applied to IPv6.
NBS, being a CEE architecture, would require
adoption of the Locator / Identifier Separation
model which would burden all hosts with
extra traffic, extra delays and extra
complexity.
Hi Javier,
Thanks for your reply, in which you wrote:
>> ... For
>> instance, it is important to note that NBS is only practical for IPv6
>> and that like most or all other Core-Edge Elimination architectures,
>> there must be extra data transferred between any two communicating
>> hosts, and typically extra delays due to the need for lookups
>> involving a global query server system: DNS.
>
> Before I start, I'd like to say that I'm representing _my_ understanding
> of NBS. I'm hoping this is in sync with the ideas behind the NBS texts.
>
> So, on with it :)
>
> No and yes.
>
> I don't see why you would claim that it is only practical for IPv6. If
> it is due NAT:s, then please see reply below.
Christian writes that there's no way of introducing the extra things
needed for NBS into IPv4 packets without making them incompatible
with existing hosts:
http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf
Yet it turns out that only the optional packet extensions of IP
version 6 are appropriate for the name-based sockets interface:
Exchange of domain names by a transport protocol would require
support for optional packet extensions in all transport
protocols. This is not the case, however. IP version 4 does
not provide an appropriate means to exchange of domain names
either, since its optional packet extensions are either dropped,
or forwarded inefficiently, by many routers and middle-boxes.
Only IP version 6 can exchange domain names appropriately. Its
optional Destination Options packet extensions are ignored by
routers and hosts if unrecognized.
Also, for any CEE architecture such as NBS, to multihome a network,
such as a /20, would require at least two /20 prefixes of PA space,
one from each ISP. This would double address consumption - so no CEE
architecture will ever be practical for IPv4.
> Yes, there will be an initial query to DNS, and that requirement is
> ubiquitous to software today.
Please see my previous messages:
http://www.ietf.org/mail-archive/web/rrg/current/msg05906.html
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
> You need some kind of tool to get away from those horrible PA-addresses.
> The vast majority of schemes suggested on the list use one form or
> another of indirection, in NBS that indirection is using DNS. (names =>
> locators).
CEE, once fully adopted by all host stacks and all applications,
means that networks can multihome from PA space. They no longer need
unscalable PI space.
CES makes a new kind of PI space which is scalable and which can be
divided much more finely than ordinary PI prefixes advertised in the DFZ.
Both could solve the routing scaling problem. CES retains the current
naming model and CEE changes it to the "Locator / Identifier
Separation" model which many RRG people consider superior, but which
I argue is inferior.
> But, if what you are saying is that DNS needs to be queried continually
> during each session, the answer is no.
Not continually during the session, but see my previous message why
in many or most cases, the responding host needs to do a lookup (DNS
for NBS) before it can send a response packet.
>> Should the peer (page 7) do a lookup on the FQDN it gets from the
>> host and verify that the source address in the initial packet is
>> one of those returned by DNS, before sending the second packet
>> back, with the host's FQDN and this peer's FQDN to complete the
>> Initial Name Exchange?
> Not according to the existing spec.
The existing spec doesn't properly consider that many responding
hosts need to ensure that the packet they send will not go to any
other host than the one which has the Identifier which was in the
first packet.
> The existing spec (and implementation) don't assume that both sides are
> NBS capable. The names (FQDN) are piggybacked on the packets until they
> are acknowledged (or a timeout expires and legacy hosts are assumed).
Yes, but this doesn't prove to either host that the Locator which
come with the Identifier in these packets is a valid Locator for the
host with this Identifier. At this stage in the communication, the
only way of checking that is with an Identifier -> Locator(s) lookup,
which in NBS is a DNS lookup of the FQDN which arrived in the packet.
>> How is this exchange secured against the reply being spoofed by
>> an attacker? (Maybe it doesn't have to be.)
>
> ATM, it's not secured. This is definitively worth exploring further.
Yes.
>> How are the Initial Address Exchange and subsequent Address
>> Exchanges secured against spoofed packets?
>
> ATM, it's not, also a point that needs to be explored.
This is what I am doing. Thanks for discussing it.
>> In these Address Exchanges, should one host accept IP addresses
>> from the other host if these do not appear in the list of
>> IP addresses returned by a DNS lookup of the other host's name?
>
> Initially, no. But after the initial few packets and the name exchange
> has completed alternative locators may be exchanged (a'la shim6
> perhaps).
But each host has to do an Identifier -> Locator(s) lookup before it
can trust the Locator which arrived in a packet really is a valid
locator for the host whose Identifier arrived in the packet.
>> How does NBS perform the equivalent of "round-robin DNS" - where
>> a FQDN DNS lookup returns multiple IP addresses, each one being
>> for a separate host? Initially I thought that the FQDN played
>> the role of both "Text name" and "Identifier", with the role of
>> "Locator" being played by one or more IP addresses. However, to
>> do this load-distributing "round-robin DNS", NBS hosts must
>> distinguish between other hosts not just by their FQDN, but the
>> combination of a single FQDN and one or more IP addresses.
>
> Good point, but I don't see this as a great problem. It's a local policy
> decision. A trivial solution could be to pick a random IP from the
> returned set. And let the two communicating peers manage the rest (by
> exchanging sets of IP).
Christian really needs to answer this. I can imagine a more complex
construct for "Identifier", such as "combination of FQDN and one or
more Locators from the set of allowed Locators returned by DNS. But
it is messy, more complex than the Identifier construct of other CEE
architectures I know of so far - and it is not necessarily what
Christian has in mind.
>> Alternative critique
>> --------------------
> <*snip*>
>> NBS cannot be introduced for IPv4. It could be introduced without
>> disruption to IPv6, using a Destination Options extension header.
>
> Why not IPv4?
As noted above.
>> As with other CEE architectures, the benefits of portability,
>> multihoming, inbound TE and mobility only apply to communication
>> sessions conducted with other hosts whose stacks and applications
>> have been upgraded to be NBS-aware. This would make it difficult or
>> more likely impossible to achieve the wide-enough adoption necessary
>> for substantial routing scaling benefits - or substantial benefits to
>> the adopters.
>
> This is an interesting point. I understand your thought (and I
> disagree).
> The point where I think we disagree is, which of the following is most
> likely to happen first:
> * A majority of network operators upgrade their equipment.
> * A majority of end-hosts upgrade their stacks.
Maybe so - but it would take a decade or more before 99% of stacks
had the new features.
The stack upgrade is the easy part.
Each application would need to work with a mixture of NBS hosts and
applications and and non-NBS hosts and applications, and be able to
operate without an NBS stack. Writing and debugging this would be
absolute hell.
Upgrading all applications to do NBS would be a complete nightmare -
it will never happen. The same goes for all other CEE architectures.
>> Ubiquitous adoption of NBS would involve every host in greater
>> routing and addressing responsibilities. These include DNS lookups
>> before responding to a request to open a session, in order to check
>> that source address of the request is one which is returned in a DNS
>> lookup of the FQDN supplied in the request.
>
> I don't think this is necessary, today we resolve a FQDN, pick our IP
> and happily talk with it.
Not with CEE - if you want to know which host you are sending the
reply packet to, you need to do a lookup to find that host's set of
allowable Locators first.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
