On Wed, 2010-02-03 at 11:12 +1100, Robin Whittle wrote: > 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:
Sorry, that slipped my mind. http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf However, talking to Christian I have understood there is a route to overcome this. I don't feel to confident on the details, so I'll happily leave that for a later e-mail. :) > 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. Here's a good point, one that I don't feel I have an immediate answer to (which is good :) However, to extrapolate that to "... no CEE architecture will ever be practical for IPv4." is quite a jump. My spontaneous reaction is "more NAT". My guess is also that I'm quite alone on this list not to consider NAT to be an abomination from the 6th circle of hell. :) Hosts have become pretty good at perforating NATs, and infrastructures for e.g. STUN and Teredo are ubiquitous, readily available and free to use. I'm going to have to return this point. > > > 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 > Yep, moved over the rest of that discussion to that thread. > >> 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. > I don't really see why you _have_ to do this. Why do you _have_ to have verification at the network/transport layers? In the FQDN => IP world we live in, this authentication is done at the application layer (and that is where it, in my opinion belongs). Again, see the "Re: [rrg] Another concern about using FQDNs as host idenfieirs//re: A concern with ILNP//re: critique of RANGI" thread. > >> 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. I don't understand why this should be a complex matter. A trivial solution: DNS rotates the order of the IPs in the reply. The NBS host picks the first address. The rest of the communication is dealt with between those two endpoints. There is no shared state, there are no more lookups in DNS, the relation betwen FQDN and IP is no longer important, the FQDN-string has been degraded to a localscope handle. > 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. If the implementation is backwards compatible, this should be trivial. // Javier
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
