Le 2012-03-27 à 13:12, Maoke a écrit : > 2012/3/27 Rémi Després <despres.r...@laposte.net> > With TTL transparency added, I don't see what would be missing, even with all > requirements you expressed. > > well, it is still uncertain how 4rd-u will do this. it is uncertain if the > new ad hoc complement doesn't introduce new problems. could we see it by the > end of IETF83?
Sure. basic ID: - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bits 1-7 of the hop count. - A exit, take bit 0 from the hop count, and bits 1-7 from the packet ID. The only constraint it introduces is that the longest IPv6 path within the domain must not exceed 127 (something that AFAIK shouldn't be a problem) OK? RD > > thanks, > maoke > > > Regards, > RD > > >> >> >> so long, >> - maoke >> >> >> >> >>> d) I didn't see any reference to TTL = 1 in the EBGP of RFC2260. Do you >>> know a better reference than this RFC? >>> >>> RFC2260 is informational rather than standard. BGP4 specification is >>> RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = >>> 1, as i mentioned, is not a standard feature, but used in some >>> implementations (including Cisco IOS and Juniper JUNOS and the open-source >>> routing tool Quagga, to my best knowledge) in order to ensure the standard >>> feature that defaultly EBGP is established over an immediate link. as a >>> quick evidence of the implementation, in bgpd.c of quagga suite we may read >>> the piece of source code: >>> >>> peer->ttl = (peer_sort (peer) == BGP_PEER_IBGP ? 255 : 1); >>> >>> it is saying, if the peer is IBGP, the TTL of IP header carrying it should >>> be set to 255; while if it is EBGP, TTL should be 1. >> >> Not familiar enough with the subject to know whether these implementations >> cannot be configured so that they don't care. >> I noted that RFC4271 doesn't have the word virtual link, and that RFC2328 >> only mentions "configured" virtual links (=> out of scope). >> >> If, despite this, you get WG support for a requirement of "1hop-only >> tunnels", the best answer is IMHO to include its support in 4rd-U. >> This AFAIK will close this issue. >> >> Thanks for this clarification, >> RD >> >> >>> >> > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
