On Sat, 2010-01-30 at 01:30 +1100, Robin Whittle 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. Yes, there will be an initial query to DNS, and that requirement is ubiquitous to software today. 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). But, if what you are saying is that DNS needs to be queried continually during each session, the answer is no. > 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 (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). > 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. > 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. > 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). > 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). > > 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 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. > 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. // Javier
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
