Ok, we include the additional stuff in the mh solution when we need it. Regards, marcelo
> -----Mensaje original----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 02 de febrero de 2004 7:36 > Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Asunto: RE: ICMPv6: New destination unreachable codes > > > I agree with Christian and Pekka here. > > So I think, we mostly agree upon the text that I had sent out > and I don't have to make any changes to that. > > > -----Original Message----- > > From: ext Christian Huitema [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 31, 2004 1:04 PM > > To: Pekka Savola; marcelo bagnulo > > Cc: Gupta Mukesh (Nokia-NET/MtView); [EMAIL PROTECTED] > > Subject: RE: ICMPv6: New destination unreachable codes > > > > > > > But this is just an operational procedure, which needs to > > be stated in > > > the multihoming solution documents, but something that IMHO must not > > > be added to the ICMPv6 spec, as it's really out of scope from ICMP > > > perspective. > > > > I agree with Pekka. The purpose of the ICMPv6 document is to > > reserve the > > code and define the format. As Marcelo said, the MH code can work with > > this code and format. Let's just go with it. > > > > I understand Marcelo's concern. He (and I) would like to make life as > > good as possible for hosts in multi-homed sites. This will require > > operational rules for hosts and for routers. As I mentioned in a > > previous message, the code definition is a nice first step. > > It tells the > > host that it should try another source address. It is only a > > first step, > > because it does not tell which one. The host will have to use some > > heuristic. In some cases, e.g. when there are just two addresses, the > > heuristic is trivial. In more complex cases, having more information > > might help. But it may be a bit early to determine how this > > information > > should be passed. We could pass it in ICMP messages, but we could just > > as well use a yet-to-be-defined information protocol associating exit > > routers with allowed prefixes, or even let hosts use some cached > > knowledge from previous connections. Given the wide choices, I would > > rather not try to mess around with the ICMPv6 specification. > > > > -- Christian Huitema > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
