Re: [mobile-ip] RFC 2462 DAD optimization
I'm curious about the implementation status. I know the Windows implementation does not implement the RFC 2462 optimization - it performs DAD on every address independently. What about other implementations? FWIW The Solaris implementation does supress DAD on addresses configured using the stateless mechanism except the link local address. It does perform DAD on all manually configured addresses. My person opinion is that we should fix that implementation and other implementations that have this behavior. Forcing implementations to have more than one link-local address due to RFC 3041 (and potentially lots of them - one for every valid RFC 3041 address) since quite odd both conceptually and messy to deal with from an implementation perspective (need to track which is the real link-local address.) Erik 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: [mobile-ip] RE: RFC 2462 DAD optimization
Date:Mon, 03 Jun 2002 11:32:26 -0700
From:Charles E. Perkins [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| My questions were related whether that model should be our design goal.
Maximum flexibility. Long term we will find a way to use that.
This implies minimum assumptions, and even fewer unnecessary rules.
| Exactly -- and I am suggesting that there are enough IPv6
| addresses available so that there is no motivation to support
| the use of prefix{1,2}::1 for two different nodes on the same
| link. Maybe one of them could find a different interface ID.
You missed the point of the example. prefix1::1 and prefix2::1
were originally assigned to different nodes on different links.
Then the links were merged into one.
| I didn't yet see why enabling the behavior you suggest has
| any advantages.
The alternative is renumbering nodes sometimes. Not renumbering
is almost always an advantage.And here we're talking about the IID
part changing, so we don't even get the benefit of local connections
continuing to work using site local addresses - everything stops.
| Honestly, I think IPv6 would be better off by prohibiting
| this behavior.
I certainly disagree with that. I see no compelling reason here
to prohibit anything.
kre
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: [mobile-ip] RE: RFC 2462 DAD optimization
Date:Mon, 3 Jun 2002 11:46:03 -0700 From:Dave Thaler [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | No. In fact, I would expect that if any prefix is multilink, then all | of them should be. Why? I'm no expert on multi-link, in fact, I'm not sure I understand the need for it at all really, but nor do I know enough to object. | There is a bit that says whether to send packets to routers or just do | ND for them, which is probably what you're thinking of. Yes, that's probably it. | However, a multilink | subnet can work either way (see section 4.1 of the multilink draft), OK. | My preference is that we just ban DAD optimization in all cases. That's certainly an option. The new prefix causes several thousand nodes to all attempt DAD at the same time argument is the one which makes me hesitant to simply support this without further investigation. kre 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: [mobile-ip] RE: RFC 2462 DAD optimization
My guess is that it will just effectively mean people will not use multiple prefixes for mobile nodes. i guess so too, and therefore, i don't feel a need to provide special hack in DAD. it is not a protocol issue, but an operational matter. I agree that we don't need to change DAD here. Doing multiple DAD messages (one per home address) should be in the noise from a performance perspective. If there is a concern that a mobile node shouldn't need to send multiple binding updates, then I think that concern applies to both having multiple prefixes on the home link as well as using RFC 3041 home addresses (and presumably DHCPv6 assigned home addresses as well). With RFC 3041 a host will by default have 7 home addresses - 6 deprecated and 1 preferred temporary address - plus whatever stable (non-temporary) home addresses it has. Allowing for a single BU to the home agent with RFC 3041 home addresses requires that the home agent to maintain the set of home address each mobile node is using and e.g. treat a BU for any address in the set as applying to the whole set. The current mechanism (with ICMP Mobile Prefix Solicitation/Advertisement) only allows the HA to guess the set of home addresses when stateless address conf is used. So perhaps this part of the protocol should be extended with explicit messages from the MN to HA to indicate which home addresses it is using. Then one can always do a single BU independent of how many home addresses a mobile node is using, and idependently of how the MN has acquired those home addresses. My 2 cents, Erik 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: [mobile-ip] RE: RFC 2462 DAD optimization
| My preference is that we just ban DAD optimization in all cases. That's certainly an option. The new prefix causes several thousand nodes to all attempt DAD at the same time argument is the one which makes me hesitant to simply support this without further investigation. If that is a problem then the MAY for the optimization in RFC 2462 wouldn't be sufficient as a solution - very few implementations do the optimization today. Possible solutions to the new prefix DAD flood could be: - mandate the DAD optimization with a MUST - update RFC 2462 to day that when a new prefix is configured (past the original attachment to the link) the host MUST insert a random delay before performing the DAD. - others? But do we agree that the DAD flood when a new prefix is announced is an important problem to solve? Erik 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: Mandating Route Optimization
Dear list, this issue is taking much time and ammunition, and it's mostly wasted. We know that the decision between MUST and SHOULD will be made in the IESG, not here. It all boils down to interpreting the words of RFC2119. The make some progress, I'd like to suggest a work plan. Step 1: someone near to the IESG members asks, if we have an option at all. Even an unofficial opinion would help. Step 2: if MUST seems possible, list the reasons for it. A few use cases and pointers to research reports would be ideal. Step 3: if the IESG keeps on throwing the book at us, accept SHOULD, but add the results of step 2 to the draft. Even SHOULD with the explanations seems acceptable to me (SHOULD with teeth said John Loughney). Good reasons can be more persuasive than plain orders. -Original Message- From: ext Charles E. Perkins [mailto:[EMAIL PROTECTED]] ... I reckon that before IETF last call on any universal IPv6 mandate, the mobile-ip working group will have the responsibility to make the reasons for the mandate clear. Excellent! We already have a volunteer for step 2 :-) -- Lassi 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: Text for MLD - cellular host draft
Hesham, The text looks fine to me. Regards, Brian Hesham Soliman (ERA) wrote: Hi all, After some discussion on the list, I'd like to propose the following text for MLD in the cellular host draft: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD may be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. Consequently, hosts cannot communicate directly with each other using link-local addresses. Hence, joining multicast groups for link-local multicast addresses is not required. However, MLD is required when hosts run applications that need to join multicast groups whose scopes are larger than the link scope. Is this acceptable? Hesham 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] 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: Text for MLD - cellular host draft
After some discussion on the list, I'd like to propose the following text for MLD in the cellular host draft: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD may be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. Consequently, hosts cannot communicate directly with each other using link-local addresses. Hence, joining multicast groups for link-local multicast addresses is not required. However, MLD is required when hosts run applications that need to join multicast groups whose scopes are larger than the link scope. i still don't understand why you are trying to impose additional restriction for link-local multicast groups (maybe i'm dumb). without MLD joins for link-local multicast groups, default routers won't be able to know which multicast group the 3GPP node is interested in. there's no special text available in RFC2710 for p2p links. itojun 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: [mobile-ip] RE: RFC 2462 DAD optimization
Date:Tue, 4 Jun 2002 12:26:31 +0200 (CEST) From:Erik Nordmark [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | If that is a problem then the MAY for the optimization in RFC 2462 | wouldn't be sufficient as a solution - very few implementations do | the optimization today. It depends upon whether the problem is one that always needs solving, or just one that needs to be able to be solved. | Possible solutions to the new prefix DAD flood could be: | - mandate the DAD optimization with a MUST So, I don't think we need to do that, whatever else happens. Then we get to implementation quality and all that - in an environment where it matters, users may want to insist on implementations that work well. In any case, we would need a way to indicate which prefixes should not be DAD optimized (MUST NOT) because of the multi-link issue. | - update RFC 2462 to day that when a new prefix is configured (past |the original attachment to the link) the host MUST insert a random |delay before performing the DAD. That's certainly a reasonable approach (though I'd prase it as before configuring an address using the prefix to make it more clear that it isn't only the DAD that needs to be delayed). | But do we agree that the DAD flood when a new prefix is announced is | an important problem to solve? Like a lot of this, I suspect this may be known only when we get IPv6 nets that are really big enough that the effects can be measured. I'm not sure there are all that many. I suspect that even the IETF net won't have enough IPv6 nodes actively connected to it to run an experiment there and see what happens. kre 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: Text for MLD - cellular host draft
Hi Itojun, i still don't understand why you are trying to impose additional restriction for link-local multicast groups (maybe i'm dumb). without MLD joins for link-local multicast groups, default routers won't be able to know which multicast group the 3GPP node is interested in. there's no special text available in RFC2710 for p2p links. First some motivation in the practical situation. The GGSN has no applications, and hence there wouldn't be a link-local video distribution from it, as an example. Furthermore, I believe IPv6 ND packets are sent to the link regardless of the state of the MLD situation on e.g. a Solicited Node address -- or perhaps I have missed some text somewhere? Hence there'd be no use of the MLD for the IPv6 routing functioanality either. Obviously, there are no switches around in these interfaces. Finally, MLD packets do consume bandwidth, particularly if they need to be sent even when there is no traffic and we are just listening e.g. on our solicited node mcast address. (I'm not exactly sure how much this bandwidth is -- perhaps someone could enlighten me? At least some initial packets have to be sent, but is there a periodic refresh as well?) But I do understand that the RFCs must be followed. However, I wonder if you Brian could say something about the background for the link-local and the Solicited Node multicast address requirements, were they done specifically to allow switches to operate or for some other reason? I also wonder about text in Section 2, which says that MLD should be on all interfaces from which an application or upper-layer protocol has requested reception of multicast packets. I wonder what upper layer means in this particular case...? If it means above IP then we could argue that we are following the RFC. I also wonder if the timers -- which are configurable per the RFC -- could be tuned to minimize overhead? Finally, I have a compromise proposal. I do appreciate Itojun's point some time ago that MLD even on a p2p link would allow the router to reduce traffic to the link. This is because it would know whether there are listeners or not. Perhaps in the future there will be some new parts of IPv6, or some new applications for which this would be useful, even in a 3GPP environment. However, I do wonder about the Solicited Node multicast address case. Assuming the rules about this are in the RFC for the support of switches, could we use MLD for all link-local and global addresses, except for all nodes and solicited node multicast addresses? Given that I can't find a place where ND would depend on MLD, I think this would work well. And the case is important, as all hosts would have these addresses and would have to announce them over the network otherwise. So, the proposal is to have the following text: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD should be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. This arrangement also precludes any network switches. Consequently, hosts cannot communicate directly with each other using link-local addresses. Furthermore, none of the entities along the link will be doing any address-based switching, and all messages sent to the point-to-point link normally arrive to the other end. As Neighbor Discovery operates without relying on MLD, joining on solicited node and all nodes multicast addresses is not required. However, MLD is required for all other multicast addresses in all scopes. Jari 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]
DNS discovery thoughts
I've been thinking about the DNS discovery, as well as the larger service discovery with no 3rd party dependencies issue, for a while. Just like Steve Deering and many others I'd like the IETF to explore the larger issue, since I'm very much interested in making the future Internet more robust than what we have today. But this effort needs to be done carefully to make sure that we are solving a well-defined and well-constrained problem. Thus I think it would make sense to hold a BoF on this topic (perhaps in Yokohama if there are folks willing to work on putting such a BoF together in the very short time that remains). Level 1 of the current DNS discovery draft is likely to set a precedent that well-known unicast addresses will be allocated for services. The IETF has never done that before - we've only allocated well-known *multicast* addresses for services. Going down the path of allocating well-known unicast addresses, even if they are site-local addresses, is something I would be very uncomfortable doing, especially if it is done as a quick fix for a short-term DNS discovery solution without knowing what a potential future service discovery with no 3rd party dependencies scheme might look like. This concern appears to be shared by some other IESG members based on some discussions last week. These concerns would probably be less strong if the fixed unicast address was one part of a larger architecture, in which the reservation of fixed address was limited and necessary as part of an overall solution. Instead, it appears that this particular choice is being driven by a particular short-term problem with no apparent relationship to future and more general work. So if I was an implementor that wanted a DNS discovery solution as soon as possible, I'd just go with DHCPv6 information-request for now, while participating in the larger, and necessarily longer term, discussions about service discovery with no 3rd party dependencies. Comments? Erik 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: Text for MLD - cellular host draft
From: [EMAIL PROTECTED] i still don't understand why you are trying to impose additional restriction for link-local multicast groups (maybe i'm dumb). without MLD joins for link-local multicast groups, default routers won't be able to know which multicast group the 3GPP node is interested in. there's no special text available in RFC2710 for p2p links. Once again, I must have missed something. Why is there ever any reason to do MLD on any link-local group? - any host on link will automaticly receive all multicast traffic that is sent to link-local group, at least if it itself is listening that group. - what use would default router have for the info? There is nothing coming into link-local group from outside the link. Perhaps, the RFC just should say MAY use MLD for link-local groups, if someone really wants to do it for some reason. 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: Text for MLD - cellular host draft
From: Markku Savela [EMAIL PROTECTED] Once again, I must have missed something. Why is there ever any reason to do MLD on any link-local group? Well, from other posts here, I guess it's to help those switches and such. However, it does somewhat bother me, that we have an exact specification, and before the standard is even ready, we are already adding things that are on the verge of layer breaking. [ as far as IPv6 is concerned, anything you send to a link, is supposed to be seen by anyone on the link without any additional work] 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]
More review comments on cellular hosts...
Here are some additional review comments from various IESG reviewers: RFC 3155 should be added to the normative refs in my opinion. I'm not opposed to keeping the non-normative ref to the 2.5/3G TCP issues draft that started me on this. Another reviewer: Comments on draft-ietf-ipv6-cellular-host-02.txt 2.4.1 says that the host must support receipt of Neighbor Solicitation and Advertisement messages. But 2.5.1 says will not be sent or received which might seem conflicting at least with respect to the receive part. DAD for 3041 addresses? Will the router only have a link-local address on the link? If not, how to detect a 3041 conflicting with one of the routers addresses? 2.12 - 3041 MAY be used. Do we want something stronger? MLD: multicast services. There is no need for MLD if the host only supports the well-known (hard coded in IPv6 implementations) link local multicast addresses. MLD is not used for listening on such addresses. Only applies to all-nodes address (ff02::1). RFC2461 says that a node must join the solicited-node multicast address(es) on multicast-capable interface, and point-to-point interface are specifically treated as point-to-point - Neighbor Discovery handles such links just like multicast links. Thus per the letter of the specifications MLD must be implemented by cellular hosts. This also effects the need to support RFC2711 (section 2.10). 2.11 (IPv4 vs. IPv6). Cellular hosts should not support configured or automatic tunnels to avoid unnecessary tunneling over the air interface, unless there are no other mechanisms available. Tunneling can lead to poor usage of available bandwidth. The bandwidth concern is a reason not to *use* tunneling, but the point about it being a last resort seems to say that it would be useful to implement this. However, the text should bot support seems to mean should not implement. Same issue for section 2.13 on 6to4 tunneling. 2.15: and all useful hosts have at least a link-local address and a larger scope address. So why not say must be supported instead of qualifying it with a tautology? 2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int thus the ip6.arpa document must be referenced. Section 3 - how about adding that future IPsec algoritms might be useful/supported in the future. Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. More comments: AES is coming, should be supported in fugure. Mention this? The docuent is vague on key management. It basically doesn't say what will be used for key management, and that begs the question of what kind of interoperability will be achieved. If AKA is the solution, then this needs to be made more clear in the document. Isn't it the case that AKA is what the overall theme for 3GPP? What is needed is a clear statement on how interoperability with regards to key management will be obtained. If this is not actually known today, then the document should just say we haven't decided yet, but will decide down the road. The document lists 7 authors. This number is considered on the high side. See draft-rfc-editor-author-lists-00.txt (which is being Last Called as we speak). 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: More review comments on cellular hosts...
Thanks Thomas (and the IESG) for the comments. Some responses inline: RFC 3155 should be added to the normative refs in my opinion. I'm not opposed to keeping the non-normative ref to the 2.5/3G TCP issues draft that started me on this. Ok! 2.4.1 says that the host must support receipt of Neighbor Solicitation and Advertisement messages. But 2.5.1 says will not be sent or received which might seem conflicting at least with respect to the receive part. Right. 2.4.1 and it's latest revs that have been discussed on the list is correct here. 2.5.1 should say Duplicate Address Detection will not be initiated by the cellular host.. DAD for 3041 addresses? Will the router only have a link-local address on the link? If not, how to detect a 3041 conflicting with one of the routers addresses? Router will have only a link-local address on the link. 2.12 - 3041 MAY be used. Do we want something stronger? Well, isn't the current keyword for 3041 essentially a MAY in the v6 standards? Note also that the cellular network privacy situation is not as bad as, say my fixed IP DSL situation. The prefixes change over time, as you turn off/on the device or go temporarily out of coverage. MLD: multicast services. There is no need for MLD if the host only supports the well-known (hard coded in IPv6 implementations) link local multicast addresses. MLD is not used for listening on such addresses. Only applies to all-nodes address (ff02::1). RFC2461 says that a node must join the solicited-node multicast address(es) on multicast-capable interface, and point-to-point interface are specifically treated as point-to-point - Neighbor Discovery handles such links just like multicast links. Thus per the letter of the specifications MLD must be implemented by cellular hosts. Discussion ongoing on the list though, see e.g. Brian's e-mail. This also effects the need to support RFC2711 (section 2.10). Yes. We could clarify the text in 2.10 to say that it is required if you do MLD. 2.11 (IPv4 vs. IPv6). Cellular hosts should not support configured or automatic tunnels to avoid unnecessary tunneling over the air interface, unless there are no other mechanisms available. Tunneling can lead to poor usage of available bandwidth. The bandwidth concern is a reason not to *use* tunneling, but the point about it being a last resort seems to say that it would be useful to implement this. However, the text should bot support seems to mean should not implement. Same issue for section 2.13 on 6to4 tunneling. These have been, I believe, satisfactorily resolved after a discussion with Margaret: basically, we are letting the ngtrans design team to specify this, in the documents. 2.15: and all useful hosts have at least a link-local address and a larger scope address. So why not say must be supported instead of qualifying it with a tautology? Ok! 2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int thus the ip6.arpa document must be referenced. Sounds good. Section 3 - how about adding that future IPsec algoritms might be useful/supported in the future. Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. We actually had that at one point in time. We could add a note that some good algorithms are coming in the future. I fear that AES isn't an RFC yet. Don't want to reference I-Ds. The docuent is vague on key management. It basically doesn't say what will be used for key management, and that begs the question of what kind of interoperability will be achieved. If AKA is the solution, then this needs to be made more clear in the document. Isn't it the case that AKA is what the overall theme for 3GPP? What is needed is a clear statement on how interoperability with regards to key management will be obtained. If this is not actually known today, then the document should just say we haven't decided yet, but will decide down the road. All of the above is true, but then again this is an IP layer document and doesn't specify a complete system. Basically, I believe we are more or less equally vague with the IPv6 standards. In practise, the situation is likely the following: * IPsec in general will use IKE or its successors. * The IP multimedia system will use IPsec, but key itself via AKA-generated keys * Web, wap, etc. is likely to use TLS. I'm open to suggestions but I'm not sure exactly what we can say. Can we mandate key management and its interoperability in IPv6 standards? Jari 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 MIBs - IPv4-mapped IPv6 addresses
I think SIIT communication using v4-mapped addresses should be represented as InetAddressType ipv6(2), and InetAddress of :::x.y.z.q . What is the relationship between a zone index and an IPv4-mapped IPv6 address? Thanks! I think that some implementations provide the zone concept for IPv4 communication, but no sin_scope_id in the sockaddr_in; thus the way to provide zone info is to use AF_INET6 sockets and IPv4-mapped addresses to communicate via IPv4 on the wire. However, since the address family in the MIB is supposed to reflect the address family on the wire, ipv4z is required to represent the zone info when performing this trick. (The zone concept is useful in v4 in some of the same ways as in v6, e.g. two different zones both using 10.0.1/24) Bill 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: DNS discovery thoughts
Erik, I know there is considerable prejudice against SLP as a solution to the general problem, but it certainly is available. It supports discovery without a 3rd party. The only definitive criticism that I've ever heard about SLP is the coupling of a directory service function with service discovery. I think a place to start might be understanding what SLP does and why its critics don't like it. jak - Original Message - From: Erik Nordmark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 04, 2002 8:28 AM Subject: DNS discovery thoughts I've been thinking about the DNS discovery, as well as the larger service discovery with no 3rd party dependencies issue, for a while. Just like Steve Deering and many others I'd like the IETF to explore the larger issue, since I'm very much interested in making the future Internet more robust than what we have today. But this effort needs to be done carefully to make sure that we are solving a well-defined and well-constrained problem. Thus I think it would make sense to hold a BoF on this topic (perhaps in Yokohama if there are folks willing to work on putting such a BoF together in the very short time that remains). Level 1 of the current DNS discovery draft is likely to set a precedent that well-known unicast addresses will be allocated for services. The IETF has never done that before - we've only allocated well-known *multicast* addresses for services. Going down the path of allocating well-known unicast addresses, even if they are site-local addresses, is something I would be very uncomfortable doing, especially if it is done as a quick fix for a short-term DNS discovery solution without knowing what a potential future service discovery with no 3rd party dependencies scheme might look like. This concern appears to be shared by some other IESG members based on some discussions last week. These concerns would probably be less strong if the fixed unicast address was one part of a larger architecture, in which the reservation of fixed address was limited and necessary as part of an overall solution. Instead, it appears that this particular choice is being driven by a particular short-term problem with no apparent relationship to future and more general work. So if I was an implementor that wanted a DNS discovery solution as soon as possible, I'd just go with DHCPv6 information-request for now, while participating in the larger, and necessarily longer term, discussions about service discovery with no 3rd party dependencies. Comments? Erik 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] 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: Text for MLD - cellular host draft
As Neighbor Discovery operates without relying on MLD, joining on solicited node and all nodes multicast addresses is not required. I read join to mean the action performed on the IP stack to indicate group membership (e.g. adding the group to the list of groups listened to and notifying the link), but I don't think that's what's intended here. Perhaps more specific wording, like sending MLD reports for link-local multicast addresses is not required? Bill 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: DNS discovery thoughts
actually, SLP seems like a much better fit than DNS for the problem of discovering hosts on an ad hoc network - not just because SLP is desinged to work without an third-party server but also because service discovery seems to fit the likely use model better than host name lookup. in particular, you've got no good way of ensuring unique and meaningful host names for hosts on an ad hoc network - they can't assert their normal DNS names (even if they have such) because such assertions might conflict with DNS, or with one another - so it doesn't match DNS one RRset per name semantics at all. and the very notion of zero configuration seems to imply that such hosts don't know what their (human meaningful, user assigned) names are - they can at most advertise what service(s) they provide and their serial #s and let applications look for them. 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]
Re: DNS discovery thoughts
actually, SLP seems like a much better fit than DNS for the problem of discovering hosts on an ad hoc network - not just because SLP is desinged to work without an third-party server but also because service discovery seems to fit the likely use model better than host name lookup. in particular, you've got no good way of ensuring unique and meaningful host names for hosts on an ad hoc network - they can't assert their normal DNS names (even if they have such) because such assertions might conflict with DNS, or with one another - so it doesn't match DNS one RRset per name semantics at all. and the very notion of zero configuration seems to imply that such hosts don't know what their (human meaningful, user assigned) names are - they can at most advertise what service(s) they provide and their serial #s and let applications look for them. you seem to be mixing two things up... the former paragraph speaks about discovery of DNS server, the latter paragraph speaks about name resolution under environment without DNS server. itojun 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: DNS discovery thoughts
sorry, I was even more confused than that - I got two message threads from different groups mixed up. please disregard my previous message. actually, SLP seems like a much better fit than DNS for the problem of discovering hosts on an ad hoc network - not just because SLP is desinged to work without an third-party server but also because service discovery seems to fit the likely use model better than host name lookup. in particular, you've got no good way of ensuring unique and meaningful host names for hosts on an ad hoc network - they can't assert their normal DNS names (even if they have such) because such assertions might conflict with DNS, or with one another - so it doesn't match DNS one RRset per name semantics at all. and the very notion of zero configuration seems to imply that such hosts don't know what their (human meaningful, user assigned) names are - they can at most advertise what service(s) they provide and their serial #s and let applications look for them. you seem to be mixing two things up... the former paragraph speaks about discovery of DNS server, the latter paragraph speaks about name resolution under environment without DNS server. itojun 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]
