On May 26, 2010, at 5:22 PM, Dae Young KIM wrote: > Hi, Tony, > > I have two problems in communication: > > o I'm in fact not a routing expert, even without any field > experience. I'm just a teacher, so that I have to know clearer to > teach my students in the right direction. > > o Over more than 40 years, English is still my foreign language so > that I sometimes have a problem in extracting the full > meaning/implication out of beautiful/concise wordings. > > And so, please be patient with me a little bit more, and let me give > you an ensuing question below. > > On Thu, May 27, 2010 at 12:51 AM, Tony Li <tony...@tony.li> wrote: >> >> >> >>> Q1: What is the gain of ILNP over the current system in terms of >>> its effectiveness in reducing the IDR table size? >> >> >> ILNP allows sites to be effectively multi-homed by allowing each host to >> have multiple locators simultaneously and transitioning across locators >> seamlessly. This allows us to migrate to a PA based addressing >> architecture. > > Suppose the same situation in the current Internet that a site is > multi-homed. So, for example, my site has got two sets of PA addresses > from two ISPs. > > Then each host in my site would have two IP addresses. > > Then, think about any host transitioning across these two addresses. > > Is there any other problem with this activity than the one you > described above in terms of ILNP?
There can be at the transport or application layers, in two forms. In both cases, the issue is that a network layer address is meaningful at the network layer and not really meaningful above it, but we have collectively not done well in remembering that. For a good rant on the topic, I would suggest reading the works of Saltzer such as http://www.ietf.org/rfc/rfc1498.txt 1498 On the Naming and Binding of Network Destinations. J. Saltzer. August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL) or listening to John Day. At the Transport Layer, if the transport considers a session to be with a remote destination at a locator, and the locator changes during a session, the transport layer will not recognize it and as a result the session will fail. That, specifically, is why ILNP specifies that the locator is not included in transport layer checksums; some would argue that it should not be communicated to the transport at all. At the Application Layer, any use of a network layer address has pitfalls. You might want to review http://www.ietf.org/rfc/rfc2993.txt 2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT=74136 bytes) (Status: INFORMATIONAL) for a reminder of why IPv4/IPv4 Network Address Translation has been a headache. These issues remain in ILNP when the application uses a network layer address indiscriminately; routing protocols can have difficulties across the boundary between addressing domains, HTTP Referrals may not be meaningful, SIP/SDP can fail when it communicates the address of a communicant, and so on. The rule has to be that IF ONE IS GOING TO USE A NETWORK LAYER ADDRESS one uses the address appropriate to the peer (an "inside" address if the peer is in the same domain, and an "outside" address in other cases), or (much better) applications confine themselves to using application layer identifiers such as DNS names. > To me, it looks quite equivalent. My host will know of the two in > existence, and will switch between the two as need arises. There I disagree, or disagree in part. My DNS system will need to know of all of the addresses; my host needs to know only if it is responsible for populating them into DNS. Let me draw a picture for you. ,-. ,---------. / \ ,-' `+-+ +-+ \ ,-. ,-----. +---+ ISP 1 |R+--+R| : / \ ,-' `+DMZ+. ,+-+ +-+ : / \ /+-+ +-+-+ `---------' ; +---+ +-+ : / |A| \ | |DMZ| |C| | ; +-+ : | ISP 3 +-+-+ +-+ ; | +-+ | | | \Your / : |B| +---+---------. : ; \Domain \ MyDomain +-+ |DMZ| +-+ +-+ ; `-' \ +---+ ISP 2 |R+---+R| ; `-. ,-' `. +-+ +-+ / `-----' `---------' \ / `-' In my domain, I have two hosts: my own is A, and B is another one. In your domain, you have some host C. When B or C want to communicate with A, they ask DNS for A's set of addresses. Ideally, B gets A's "inside" address and C gets A's two "outside" addresses; more probably, each will get all three, and sort among them by discovering, in B's case, that A has an address that is "more similar" (matches a longer subset of its prefix) than the other two, or some of the addresses simply don't work. The question is how the DNS system gets A's 3 addresses. A is actually only aware of the "inside" address and will only use that; however, DNS knows the translation to the external set of addresses, and if A is posting addresses via Dynamic DNS, will do that translation when addresses are posted. If the DNS system isn't doing that, then of course A will have be aware of its addresses. > I assume we're talking about multi-homing, not mobility here > specifically in this context. If it's about mobility, I can see that > ILNP has an advantage for TCP connection is not associated with > locator while it would be with the current IP address. Actually, multihoming becomes a special case of mobility. > But as long as you were talking about multi-homing, you would not mean > fast transitioning without breaking a TCP connection. You would > implicitly mean a situation where the same host would be associated > with a connection at one point in time and with another at a different > point in time. Or even with two simultaneous yet separate connections. If the locator is irrelevant at transport and above, this also helps with the multipath TCP case. It requires the application to send not to a given remote address but to all of them, but it has that possibility. > In all these connection scenarios, I would assume that the effect > would be the same in both cases of ILNP and the current Internet. > > I must be missing a critical point here. > > But, if I'm not, wouldn't it the description of yours apply in the > same way to the current Internet? The same situation with multiple PA > addresses? yes and no; TCP in the present internet cares a great deal about the locator, and applications do as well. Shim6 tries to address those issues, but a shim6 internet is not the same as the present one either. > Remember, in my scenario, I'm not using PI addresses. > > Help me out, please. >> >> Tony >> >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >> > > > > -- > DY > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg http://www.ipinc.net/IPv4.GIF _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
