Hi Robin > I am not sure of what the difference is between "normal" and "raw > socket" applications. Can you explain this and provide some examples > of each?
A raw socket is having direct access to the network layer, therefore it should be aware of the new header, that is the RLOC and EID fields Here are some explanations about raw sockets http://msdn.microsoft.com/en-us/library/ms740548.aspx http://en.wikipedia.org/wiki/Raw_socket Not sure but suspect that at least ICMP, PING and IPsec uses raw sockets About other sockets, see http://en.wikipedia.org/wiki/Berkeley_sockets > > However, my point is that hosts using the new address space your > system provides will be unable to communicate with any application > which does not meet all these requirements: > > 1 - The application has been upgraded. > Nope, here is the trick. The application uses sockets API when setting up the connection. So the stack needs to be backward compatible towards the application but when the stack is assembling the datagram it needs to do it in the new way. It is actually the stack that is doing the map&encap, sort of. No changes to the application, unless it uses raw sockets. If the application uses stream or datagrams sockets no need to change the application. > 2 - The host stack and API has been upgraded. > Correct, the stack has been upgraded, RLOC and EID needs to be defined so that raw socket applications can access these new fields > 3 - AFAIK, the Internet service the host uses is upgraded > - which I think means all routers in that network and > its ISP need to be upgraded, and I guess sufficient > routers in the DFZ between the ISP used by both hosts. > Nope, no changes to the network - for a packet to get routed the IPv4 headers destination IP address is used. But we need a new element at the destination AS (remote RLOC domain), that is the LISP Switch Router. Actually, this doesn't need to be a router, it could be a server attached to the network doing the several steps I described in the draft > 4 - Also, I think there are some upgrades required in > DNS servers. Yes, DNS and to distribute the local RLOC identifier to the host extension is needed to the DHCP. ICMP needs extensions as well. A lot of work and drafts are needed to get the details defined, first we need a blue print covering the framework. This proposal is not a network only issue, it goes through all disciplines > > BTW, I am not sure why you reference LISP in your I-D. In what ways > does your system resemble or differ from LISP-ALT, for instance? You > don't mention ITRs and ETRs. > Without LISP teams work and spreading the message I wouldn't be writing this now. Run into LISP in Barcelona Jan 2008 and that presentation changed my way of thinking. But since the LISP team has defined that the host must be untouched I can't say that this proposal is a LISP solution, but what I'm doing is that LISP gets pushed to the edge by implementing the map&encap in the host's stack - and the applications will not be aware of the changes. LISP-ALT is not needed if we add the RLOC identifier to the DNS records. And the network gets a lot simpler. Also on the edge (hosts) we have the most CPU resources, but the other side of the coin is that it is not a network only issue anymore. That's the reason, the LISP people is part of the draft though they don't know about it. > I only read your draft enough to be convinced it wasn't viable, for > the reasons I described. I assume that you are somehow generating a > larger global address space of some kind than is possible with 32 > bits. However, I don't see this clearly documented in your I-D. > > Your I-D starts with some broad analogies, then some goals and > definitions of terms. Then there are a list of extensions to > existing protocols, a new type of IP header, I think, to replace > IPv4, and then there is mention of a "LISP" header. In section 6 I > think we get some idea of how you intend your system to work: > > 1. The client queries the DNS server; the hIPv4 stack notice that > the local and remote RLOC doesn't match and therefore must use > the hIPv4 header for the connection. > > but I haven't been able to fully understand it. Sorry for my bad writing, I have time constraint and I can work on it whenever I can find time - this is not my primary task > > Does this mean that every connection involves identifying a host via > its DNS name? If so, then I guess your system wouldn't support using > an IP address to identify a host. A single 32 bit IP address clearly > isn't enough, so I guess the new addressing arrangement means that a > host is defined by a 32 bit RLOC address and a 32 bit address which > only identifies an actual host within the scope of a namespace > specific to that RLOC, or to a number of RLOCs in the same AS. > When this is fully implemented every AS can have its own IPv4 address space, except an IPv4 address block (Global RLOC Block, GRB) that we need to assign to identify the AS. Since the AS identifier (RLOC identifier) is only distributed between the AS we can have overlapping IP address blocks as long they are not connected to the same AS. So if a SME in Finland is assigned an IP address block 192.168.1.0/24 the very same IP block can be assigned to another SME in Australia, the US, France, etc because most likely the Finnish service provider will never be present in those countries. If a global service provider is used, there could be some more restrictions but the global SP most likely uses BGP in its network anyway and thus the global SP will have several AS (and RLOC identifiers) anyway. So this draft enables that we can a hierarchical IPv4 addressing space. RLOC identifies the AS (how to route to the destination AS) and once we are there we look into the local RIB in order to find the final destination. It is like traveling, first you decide which Times Square you are going to - London, New York, Sydney or Hong Kong. Then order a air ticket to e.g. Hong Kong, at this moment I don't care about the "RIB" of Hong Kong but once I get through the customs I get the local map (RIB) to find a route to Times Square. Having similar structure to the IPv4 addressing scheme, that is that the DNS returns a two level A-record: the IP address of the AS and the IP address of the final destination. If we reserve, let say, 1 million IP addresses for the GRB we can have about 1000000*(4,294,967,296 -1000000) addresses, good enough. And the beauty is that the forwarding plane is already in place and by making changes to the stack and keeping the socket API intact there is no need to have a major forklift upgrade. And the DFZ gets smaller, in the end of the day you have your local RIB and from the global only the GRB prefixes > >> And >> the new and old addressing scheme is compatible as long as the current >> distribution of IP prefixes are in place - once the routing >> information is started to get suppressed the old IPv4 stack can no >> longer communicate outside their AS. Within the AS we will use the >> legacy IPv4 stack, now and forever. > > OK, but I don't see how you can motivate people on an entirely > voluntary basis to adopt a new scheme, with the new kind of address > space only accessible from other systems which have already upgraded. > If my host is using the legacy stack and though DNS returns RLOC info for the destination my host should use the IPv4 scheme - and vice verse. If my host is using the hIPv4 framework and DNS returns RLOC information I can use the new framework though the old network is still in place. Here is a smooth transition. > >> The stack will be modified but the API is still the same with some >> extensions needed for the raw socket applications. >> >> Also if you add new features (such as mobility) to the stack you can >> create a demand to have it upgraded, > > You haven't described how mobility would be implemented, nor why it > would be attractive to large numbers of people if it only worked with > the subset of hosts which had upgraded applications, stacks, Internet > connections etc. Please have a look on these two proposals http://nms.lcs.mit.edu/papers/e2emobility.pdf ftp://ftp.cs.wisc.edu/paradyn/papers/Zandy02Reliable.pdf Both proposals need changes to the stack but since this proposal requires changes to the stack here is golden opportunity to take mobility to the next level Hope this help to understand what I have been trying to write in the draft And we should a very skilled specialist onboard to have a look on the proposed changes for the stack and socket API, I admit that I do not have enough skills since my background is networking. But since the rocks and racks (Zandy02Reliable.pdf) are able to cheat the application about change of the underlying IP address there should be a chance that this actually could be implemented. That is, no code is available, this is an idea that I find interesting -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
