Rsvp IPv6?
Hello everybody, How can we use RSVP with IPv6? It seems flow label is not well defined so send me, please, all informations about the future of this field. Thanks. BR, Fayçal. 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]
Anycast address implementations
Hi- I'd like to know if anyone can shed light on this matter. RFC 2373 (IPv6 Addressing Architecture) defines IPv6 anycast addresses and notes that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. Who defines nearest and how is it defined? Do the anycast routers communicate with each other and elect a router to perform the metrics? I assume these metrics are measured with respect to the source address? I'd also be interested in hearing any real world experiences with anycast addresses, such as inefficiencies, etc., and how anycast addresses are limited in practice, such as if anycast address participants must be defined on a router a priori elected to serve as the address coordinator, etc. Best regards, John Wells -- John WELLS ENSIMAG/3A Télécomm/Réseaux - INRIA Rhône-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab 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: a tiny comment on getnameinfo (rfc2553bis-03)
This is fixed in the Austin spec (http://www.opengroup.org/austin) and so should get folded back into rfc2553bis when the two specs are aligned. Section 6.2 of draft-ietf-ipngwg-rfc2553bis-03.txt has the following text: If the argument node is non-NULL and the argument nodelen is nonzero, then the argument node points to a buffer able to contain up to nodelen characters that will receive the node name as a null-terminated string. If the argument node is NULL or the argument nodelen is zero, the node name will not be returned. If the node's name cannot be located, the numeric form of the nodes address is returned instead of its name. If the sa argument is an IPv6 address the returned nodename may be in the format as defined in [5]. However, the corresponding function prototype just described before the paragraph does not contain the arguments node and nodelen: int getnameinfo(const struct sockaddr *sa, socklen_t salen, char *host, socklen_t hostlen, char *serv, socklen_t servlen, int flags); I think the notation should be consistent; if we leave the function prototype as is, then the text should be rewritten using host instead of node, and hostlen instead of nodelen. Similarly, a succeeding paragraph has a same kind of problem: If the argument service is non-NULL and the argument servicelen is nonzero, then the argument service points to a buffer able to contain up to servicelen characters that will receive the service name as a null- terminated string. If the argument service is NULL or the argument servicelen is zero, the service name will not be returned. If the service name cannot be located, the numeric form of the service address (for example, its port number) is returned instead of its name. there are no variables service and servicelen in the prototype. 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: Anycast address implementations
Anycast is implemented as a host route, and as such the anycast routers don't communicate anything other than their normal routing updates. The distance is not measured, and is strictly a matter of normal routing finding the closest router that has some host behind it willing to answer to the anycast address. As you might guess any long running connection with one of these hosts is subject to routing flaps, with the resulting connection reset when packets appear at a different host than the previous ones did. As such it is much better suited to transaction applications like DNS than long lived applications like FTP. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Wells Sent: Wednesday, April 25, 2001 9:12 AM To: [EMAIL PROTECTED] Subject: Anycast address implementations Hi- I'd like to know if anyone can shed light on this matter. RFC 2373 (IPv6 Addressing Architecture) defines IPv6 anycast addresses and notes that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. Who defines nearest and how is it defined? Do the anycast routers communicate with each other and elect a router to perform the metrics? I assume these metrics are measured with respect to the source address? I'd also be interested in hearing any real world experiences with anycast addresses, such as inefficiencies, etc., and how anycast addresses are limited in practice, such as if anycast address participants must be defined on a router a priori elected to serve as the address coordinator, etc. Best regards, John Wells -- John WELLS ENSIMAG/3A Tilicomm/Riseaux - INRIA Rhtne-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab 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]
nonexisting destination on p2p link
we observed certain packets goes ping-pong on p2p link. it depends on: - how p2p links are implemented on the stack - how routes to p2p links are configured (this highly is implementation dependent) but anyway, i would like to have your second opinion. KAME code has a special code (disabled by default) for this case, like - suppose I am a router. if the packet comes in from interface Ix, and goes out again to Ix, and interface Ix is a p2p link, I do not forward the packet. instead, I'd emit ICMPv6 no route to host. questions: - is my scenario make sense? or do we have some implementation mistake? - is the KAME special behavior look legal? - are there any implementation that chokes with it? for example, are there implementation that do not check the local address on p2p link, and expect the packet to come back again? - if it looks legal, what ICMPv6 type/code should be used? timexceeded? - how should we document? (if you are curious about the source, see #ifdef PROHIBIT_P2PREDIRECT in sys/netinet6/ip6_forward.c in KAME tree). itojun scenario: suppose we have routers A and B, and they are connected by some p2p link (tunnel, ATM, whatever). case 1: consider link local address (La and Lb). A (La) --- (Lb) B A has fe80::/10 (or fe80::/64 depending on your implementation) route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a destination, it will reach B. then B forwards it back to A. then A forwards it back to B, ... until hoplimit field goes 0. also, they would emit ICMPv6 redirect to the peer, since the packet gets forwarded back again to the incoming interface. case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a single /64 prefix, P::/64. A (Ga) --- (Gb) B A has P::/64 route pointed to the p2p link. if A emits a packet with Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same story as above. note that, as P::/64 is global or sitelocal prefix, remote node can generate the ping-pong packet and chew up the bandwidth on the p2p link (so it may be a security issue). NOTE: gated models p2p links differently. 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: nonexisting destination on p2p link
Hi, I think theorically REDIRECT should be sent over the p2p link, but dropping the packet is a better sanity check !! suppose we have routers A and B, and they are connected by some p2p link (tunnel, ATM, whatever). case 1: consider link local address (La and Lb). A (La) --- (Lb) B A has fe80::/10 (or fe80::/64 depending on your implementation) route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a destination, it will reach B. then B forwards it back to A. then A forwards it back to B, ... until hoplimit field goes 0. also, they would emit ICMPv6 redirect to the peer, since the packet gets forwarded back again to the incoming interface. Well if Lx is link-local, it should not bie forwarded at all ? case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a single /64 prefix, P::/64. A (Ga) --- (Gb) B A has P::/64 route pointed to the p2p link. if A emits a packet with Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same story as above. note that, as P::/64 is global or sitelocal prefix, remote node can generate the ping-pong packet and chew up the bandwidth on the p2p link (so it may be a security issue). A way to avoid this may be to have only /128 prefixes for non-local adresses for p2p interfaces, on A, p2p interface dump will have something like p2p_if: (La) / 64 (Ga)/128 -- (Gb) so only Gb will be reachable through the link. Is it considered too restrictive ? or what is the use of a P::/6' on a p2p link ? Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 Address : 6WIND 1 place Charles de Gaulle Immeuble Central Gare 78180 MONTIGNY LE BRETONNEUX FRANCE web site : www.6wind.com 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: nonexisting destination on p2p link
case 1: consider link local address (La and Lb). A (La) --- (Lb) B A has fe80::/10 (or fe80::/64 depending on your implementation) route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a destination, it will reach B. then B forwards it back to A. then A forwards it back to B, ... until hoplimit field goes 0. also, they would emit ICMPv6 redirect to the peer, since the packet gets forwarded back again to the incoming interface. Well if Lx is link-local, it should not bie forwarded at all ? in the existing RFCs, there's no wording that forbids forwarding packets to link local address, **given that we forward it back to the same link**. A and B are forwarding packets back to the same link. we cannot forward packets with linklocal address across different links. this part is clear but we are not talking about this. attached is hypothetical example I made to bill. case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a single /64 prefix, P::/64. A (Ga) --- (Gb) B A has P::/64 route pointed to the p2p link. if A emits a packet with Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same story as above. note that, as P::/64 is global or sitelocal prefix, remote node can generate the ping-pong packet and chew up the bandwidth on the p2p link (so it may be a security issue). A way to avoid this may be to have only /128 prefixes for non-local adresses for p2p interfaces, on A, p2p interface dump will have something like p2p_if: (La) / 64 (Ga)/128 -- (Gb) so only Gb will be reachable through the link. Is it considered too restrictive ? or what is the use of a P::/6' on a p2p link ? as mentioned earlier on the email, this really depends on how you model p2p interfaces. from IPv4 practice, gated uses /128 (err, /32) routes to p2p interfaces. cisco uses /64 (err, /24 or whatever) routes to p2p interfaces. we cannot say which one is right and which one is wrong. my original queestion is, if we are taking cisco model, (P::/64 points to p2p interfaces), what is the right behavior for us? itojun Why would you ever want to forward a packet with a link-local destination address? A | ==+===+== | | B C hypothetical example - if B has misconfigured and throws packets toward C's link local address to A, A may want to forward it to C and throw icmp6 redirect. (yes, B is broken) was there any spefic wording that we shouldn't? i guess not, so we do not have any special forbid from forwarding rule yet. if the packet is addressed to someone else, we forward it. itojun
