test2
test2 IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 Link-Local Use Issue for Applications
> > The solution that will work for now is make a statement in the > > IETF and in industry IPv6 implementation documentation that > > link-local addresses SHOULD not be used as an IPv6 address > > type by applications. > > Jim, this is simply pointless. I haven't gotten through all the mail yet so > somebody has probably already pointed this out, but you can't use an ad-hoc > network without routers if the apps won't bind to a LL address. that's okay, you can't use ordinary apps with LL addresses (even on ad hoc networks) if the hosts on which those apps run have more than one active network interface. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Fourth alternative [was Re: Moving forward ....]
On Tue, 19 Aug 2003 18:04:05 -0700 "Tony Hain" <[EMAIL PROTECTED]> wrote: > Erik Nordmark wrote: > > ... > > FWIW, I think a multi6 solution with id/loc separation will > > make the local addressing concerns go away. > > Well a 'solution' might do that, but I don't see one happening in our > lifetimes. Any separation will require a mapping infrastructure to > dynamically bind the values back together. agreed. > Such a mapping infrastructure > will have all of the scaling concerns of DNS, Not clear. Nothing says that the mapping service has to be organized like DNS. It is not inherently necessary (though quite possibly desirable) that assignment of stable IDs be federated similarly to the way address blocks are federated, so that the service can do mapping on a per-block basis rather than a per-address basis. However, there is no inherent reason that the servers that provide the mapping have to be provided by the assignees of those ID blocks. Nor is there any inherent reason that propagation of updates has to be like DNS. > plus the constraint that its > convergence times are extremely short. There is no well-known technology for > running a global multi-master, cross trust boundary, database, with > appropriate caching for scale, and convergence times that are useful for > application failover. What would you call BGP then? Granted, it's not exactly a database, but it's certainly "multi-master" and "cross trust boundary" and it at least attempts to converge within a timeframe in which apps can fail over. I'm not claiming that defining this mapping infrastructure is an easy problem - certainly it is not. However it doesn't seem like a good idea to assume that it needs to look like DNS. If anything, it's precisely because we know the pitfalls of DNS, that we should look for a somewhat different solution. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: IPv6 Link-Local Use Issue for Applications
Jim, I'm not arguing that general-purpose apps should do anything special to support link-local addresses. For the most part, I doubt they'll ever see them, since link-local addresses won't be in the DNS. But then again, I don't think that most apps need to do anything to discourage their use with link-local addresses. A standard server listening on some TCP port, accepting connections, and just chatting with the peer over that stream, doesn't need to care whether the client is using a global or a link-local address. TCP will remember the scope-id internally as part of the endpoint. The app never even sees it. And if the app does extract the address via getpeername or whatever, it'll get the scope-id as part of the sockaddr_in6. If it subsequently opens another connection to the peer using that sockaddr_in6, it'll connect to correct peer. So I think the existence of link-local addresses is a non-issue for most of the world's application writers. The only potential concern I see here is with apps that are specifically designed to be ad-hoc apps. How does the initiating node get the link-local address of its peer in the first place, since link-local addresses are not in the DNS? Others have pointed to LLMNR as being designed for this purpose, or maybe some other type of discovery mechanism will be used. Regardless of that issue, I think proper link-local support is a major selling point for IPv6. The ad-hoc scenario using link-local addresses is another place where IPv6 has a much better story than IPv4. In the IPv4 world, multiple OS vendors are today shipping a solution where if the machine doesn't hear a DHCP server it goes into an "ad-hoc" mode where it creates an address in the 169.254/16 space. With only 16 bits of numbering space for nodes, the possibility of collisions is much greater than for IPv6. And the lack of a scope-id field in the sockaddr_in means that if nodes on two links do collide, another IPv4 node on both of those links has no way to disambiguate the two. IPv6 handily solves this problem today. --Brian > -Original Message- > From: Bound, Jim [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 20 August, 2003 07:27 > To: Brian Zill; [EMAIL PROTECTED] > Subject: RE: IPv6 Link-Local Use Issue for Applications > > > Brian, > > Aware of how it could be done and we had to put link-id in > our first R&D stack back in 1995 when we saw this then. My > contention is for multiple links the state to be maintained > to send a packet to the right link with no probe from network > peer (telling node what link it is speaking to the initiator > on) is far to cumbersome to ask Oracle, SAP, or Peoplesoft to > be aware of to port to IPv6. > > Glad you agree on not putting these in the DNS too. > > thanks > /jim > > > -Original Message- > > From: Brian Zill [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 18, 2003 11:00 PM > > To: Bound, Jim; [EMAIL PROTECTED] > > Subject: RE: IPv6 Link-Local Use Issue for Applications > > > > > > Jim, as long as the application is link-local aware, and > > treats the scope-id properly, this is not a problem. Most > > stacks I'm aware of handle this situation correctly. But > > this means getting the address directly off something on the > > link, and not through some external lookup mechanism like the > > global DNS. Link-local addresses are ambiguous off link, and > > therefore should not (or rather, MUST NOT) appear in the > > global DNS. For the most part, this limits the use of > > link-local addresses to applications that are aware of the link. > > > > --Brian > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bound, Jim > > > Sent: Monday, 18 August, 2003 18:01 > > > To: [EMAIL PROTECTED] > > > Cc: Bound, Jim > > > Subject: IPv6 Link-Local Use Issue for Applications > > > > > > > > > Folks, > > > > > > Below is a picture of two links: Link 1 and Link 2. Link 1 has > > > Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. > > > A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. > > > All hosts have both a Link-Local address FE80:: and a Global > > > Address 3FFE:YY::. Note that Host-L1-B and Host-L2-E have the > > > same Link-Local address as FE80::MAC1. This is > permitted in IPv6 > > > for separate links. > > > > > > > > > Host-L1-BHost-L1-C > > >3FFE:AB::MAC1 3FFE:AC::MAC2 > > > FE80::MAC1FE80::MAC2 > > > Link 1 ___|_|___ 3FFE:AD::MAC3 > > > |FE80::MAC3 > > > > > > |--- Host-LX-D0 > > > > > > |FE80::MAC6 > > > > > > Link 2__|3FFE:A0::MAC6 > > > | | > > >FE80::MAC1FE80::MAC5 > > > 3FFE:AE::MAC1 3FFE:AF::MAC5 > > >Host-L2-E Host-L2-F > > >
RE: IPv6 Link-Local Use Issue for Applications
> that's okay, you can't use ordinary apps with > LL addresses (even on ad hoc networks) if the > hosts on which those apps run have more than > one active network interface. Huh? I do this all the time. I daresay a lot of other readers of this list do too. Could you clarify what you mean by this? --Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Moving the ipng mailing list
Folks, After many years of service Sun Microsystems has indicated that they can no longer administer the ipng mailing list of the IPv6 working group. Consequentially, we will be moving the list in next two or three weeks. Sun will continue to manage the list through the transition. We first want to thank the folks at Sun for keeping the list going and dealing with bounces, spam, and all of the other things that come up with a large public mailing list. This has been an important contribution to the IPv6 working group and the IETF in general. Thank you!!! The current plan is to move the list to ietf.org. Everyone currently subscribed to [EMAIL PROTECTED] will be subscribed to the new list. You will not have to subscribe to the new list if you are currently subscribed to the old one. This should keep the disruption of moving to a minimum. Once the new list is set up and announced as operational, we will ask Sun to setup a fixed error message in response to any posting to the old address saying the list has moved and ask the sender to resend the email to the new list address. We need a volunteer to be the list owner to handle the bounces, SPAM, etc. This is an important job. If you are interested in doing this, please respond directly to the chairs and include any experience you have doing this for other lists. Having a few people share this job would be fine. One small point. The list is currently named "ipng". We could keep the name the same or change it to "ipv6" to be consistent with the current name of the working group. Please let the chairs know if you have a strong preference one way or the other. More news later as the details get worked out. Thanks, Bob Hinden and Margaret Wasserman IPv6 w.g. chairs IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 Link-Local Use Issue for Applications
On Wed, 20 Aug 2003 17:18:02 -0700 "Brian Zill" <[EMAIL PROTECTED]> wrote: > > that's okay, you can't use ordinary apps with > > LL addresses (even on ad hoc networks) if the > > hosts on which those apps run have more than > > one active network interface. > > Huh? I do this all the time. I daresay a lot of other readers of this > list do too. Could you clarify what you mean by this? To a host with multiple network interfaces, an LL address by itself means nothing unless the host is willing to try contacting that address on each of those interfaces. Even then, the host cannot assume that the address is valid to other hosts that are participating in the app. So LL addresses are unreliable for apps that do referrals. If you have something like LLMNR, or if you specify an address literal, the host that does the lookup can know which interface to use. But this doesn't solve the problems with referrals. Also, in order for LLMNR to work properly (i.e. for it not to break apps) it must always return results that are consistent with DNS (when given a query for a DNS name). It's very tricky to associate LL addresses with DNS names, even in LLMNR, and to do so in such a way that it won't cause problems for apps that need consistent results from DNS. Part of the problem is that the DNS might more-or-less concurrently appear "up" to one host and "down" to another host even though both hosts are participating in the same app, so one host might be querying LLMNR while another host in the same app is querying DNS for what should be the same information. Bottom line - it's not safe to associate LL addresses with DNS names, even if you're using LLMNR as the lookup mechanism. Now if you want to have "local" names (names that don't look like DNS names) associated with LL addresses, and you want to use LLMNR to map those names to addresses, you can do that without confusing apps that make the (reasonable) assumption that lookups of DNS names are consistent from one host to another (modulo zone updates that change serial numbers). But that implies that the apps are aware of local names, i.e. that local names are treated differently from DNS names by the apps. And it still doesn't solve the problem that LL addresses are not reliable in referrals. Of course you can get away with using LL addresses with some apps, under some circumstances, because sometmes LLMNR looks "enough like" DNS to fool the app. If you're sufficiently clever about those apps you won't even try to use them when they wouldn't work, so you won't be annoyed when those apps fail. But that doesn't mean that LL addresses are reliable for ad hoc networks for ordinary users, unless all of those users have hosts with only one active network interface, and all are connected to the same (perhaps bridged) link. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
>>> Erik Nordmark wrote: >>> FWIW, I think a multi6 solution with id/loc separation will >>> make the local addressing concerns go away. If it provides something that is almost as good as PI. >> Tony Hain wrote: >> Any separation will require a mapping infrastructure to >> dynamically bind the values back together. > Keith Moore wrote: > agreed. Ditto. >> Such a mapping infrastructure >> will have all of the scaling concerns of DNS, > Nor is there any inherent reason that propagation of updates > has to be like DNS. Agree. > plus the constraint that its convergence times are extremely short. > There is no well-known technology for running a global multi-master, > cross trust boundary, database, with appropriate caching for scale, > and convergence times that are useful for application failover. It is not needed as long as the id/loc system does not need the full database to be fully replicated all over the world at all times. In other words, the requirements for that global multi-master, cross trust boundary database can be lessened by an id/loc system that could accommodate a partial picture as a bootstrap phase for its own mapping, and the convergence time can be brought by the id/loc protocol instead of database convergence. > What would you call BGP then? Granted, it's not exactly a database, > but it's certainly "multi-master" and "cross trust boundary" and it > at least attempts to converge within a timeframe in which apps can > fail over. I think that for practical purposes it's close enough of the definition of a database. Granted, it is not nearly as complex as OSPF but it could be called a database. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 Link-Local Use Issue for Applications
> I'm not arguing that general-purpose apps should do anything special to > support link-local addresses. For the most part, I doubt they'll ever > see them, since link-local addresses won't be in the DNS. > > But then again, I don't think that most apps need to do anything to > discourage their use with link-local addresses. A standard server > listening on some TCP port, accepting connections, and just chatting > with the peer over that stream, doesn't need to care whether the client > is using a global or a link-local address. really? what is a "standard" server, anyway? a SIP server certainly does care. an HTTP server that returns redirects might care. lots of servers log IP addresses, and they care at least to the extent that they might want to log the scope_id or interface name of an LL address in addition to the address itself. and it would make perfect sense for some apps - in particular those that do referrals - to refuse to talk to LL addresses at all. Sure enough, you can get away with using LL addresses for some apps. but it's a big stretch to say that LL addresses are good enough for most apps. There are too many cases where they fail. LL addresses are simply not suitable for general-purpose use, not even on ad hoc networks. Keith IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Some IPv6LL operational experience
I realize that as an employee of a company that sells a product and tries to implement standards the IETF blesses to solve problems, my voice doesn't really count, but I wanted to toss in my two cents. We have been using IPv6LL addresses with some success. The next release of Mac OS X implements something similar to LLMNR that we call mDNS with support for IPv6. For the time being, the only IPv6 addresses we, or most of our customers have, are IPv6LL addresses. This combination of mDNS and IPv6LL addresses works very well. IPv6LL addresses are important to us because a multi-homed host may not have an IP address on every interface. IPv4LL addresses don't work on more than one interface because they lack a scope id. The scope id in IPv6LL addresses makes them much more compelling. IPv6LL addresses let us enable networking in situations that wouldn't otherwise work. For example, we've implemented IP and IPv6 over Firewire. In most cases, it is unlikely that an IPv4 address will be assigned to the IP over Firewire link. This is usually used in the scenario where two computers are hooked directly together. We can't assign an IPv4LL address to the Firewire interface because it causes a number of problem on a multi-homed host. The IPv6LL address is configured automatically and is always there. Very few people have the skill required to successfully type an IPv6 address, which is why the mDNS component is so important. In addition to allowing users the ability to type a name instead of an address, the question of scope id goes away. The name is resolved using mDNS. The scope id is derived from the interface the response came back from. The application is none the wiser because it gets a full sockaddr_in6 from the call to resolve the name. Applications that perform referrals may fail, but I'm not aware of any of these that are currently shipping and support IPv6. IPv6 is a new beast, we don't have to be as concerned about applications making stupid assumptions. If we explain that IPv6 link local addresses work this way and here's a list of limitations, that's good enough. The advantages of IPv6 link-local addresses far outweigh the disadvantages. IPv6LL is a major selling point. IPv6LL is a sneaky way to get everyone exposed to IPv6 and to encourage developers to start supporting IPv6. Sure, connectivity off of the local link for those of us in the US is only for a few elite, but IPv6 on the local link can solve real world problems today and work for everyone. -josh IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
