Re: qwest.net dropping packets... wife would like someone to pick them up please...
For some more information, this previous document and presentation make good resources: Document: http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf There's also a presentation here: http://www.nanog.org/meetings/nanog45/presentations/Interpret_traceroutes.wmv On Sat, Nov 3, 2012 at 11:10 PM, Randy wrote: > --- On Sat, 11/3/12, Christopher Morrow wrote: > > > From: Christopher Morrow > > Subject: Re: qwest.net dropping packets... wife would like someone to > pick them up please... > > To: "Randy Bush" > > Cc: "North American Network Operators' Group" > > Date: Saturday, November 3, 2012, 7:04 PM > > On Sat, Nov 3, 2012 at 3:07 AM, Randy > > Bush > > wrote: > > >> one router along the path showing loss that does > > not continue to > > >> affect the rest of the path simply means the cpu on > > that router > > >> is a bit too busy to respond to icmp messages > > > > > > trivial footnote: some folk configure some routers to > > rate limit > > > icmp > > > > other trivial footnote, not all traceroute is icmp. > > > True, wrt to destination. However all intermediate(including penultimate) > hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) > ./Randy > > >
Re: qwest.net dropping packets... wife would like someone to pick them up please...
--- On Sat, 11/3/12, Christopher Morrow wrote: > From: Christopher Morrow > Subject: Re: qwest.net dropping packets... wife would like someone to pick > them up please... > To: "Randy Bush" > Cc: "North American Network Operators' Group" > Date: Saturday, November 3, 2012, 7:04 PM > On Sat, Nov 3, 2012 at 3:07 AM, Randy > Bush > wrote: > >> one router along the path showing loss that does > not continue to > >> affect the rest of the path simply means the cpu on > that router > >> is a bit too busy to respond to icmp messages > > > > trivial footnote: some folk configure some routers to > rate limit > > icmp > > other trivial footnote, not all traceroute is icmp. > True, wrt to destination. However all intermediate(including penultimate) hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) ./Randy
Re: qwest.net dropping packets... wife would like someone to pick them up please...
On Sat, Nov 3, 2012 at 3:07 AM, Randy Bush wrote: >> one router along the path showing loss that does not continue to >> affect the rest of the path simply means the cpu on that router >> is a bit too busy to respond to icmp messages > > trivial footnote: some folk configure some routers to rate limit > icmp other trivial footnote, not all traceroute is icmp.
Re: IPv6 Netowrk Device Numbering BP
On Nov 1, 2012, at 8:20 AM, Masataka Ohta wrote: > We should better introduce partially decimal format for > IPv6 addresses or, better, avoid IPv6 entirely. With respect, it is already possible to use the decimal subset if you wish. For example, you could write 2001:dba::192:168:2:1 It wouldn't be very dense, but EID density wasn't the objective.
Re: IPv6 Netowrk Device Numbering BP
On 11/1/12 2:01 PM, Owen DeLong wrote: There are better ways to avoid neighbor exhaustion attacks unless you have attackers inside your network. All of the migrations are compromises of one sort or another. We thought this one was important enough to include in an informational status RFC (6583). Which approach is most appropriate (and whether it's necessary at all) will depend on the circumstances involved. If you have attackers inside your network, you probably have bigger problems than neighbor table attacks anyway, but that's a different issue. Even if you're going to do something silly like use /120s on interfaces, I highly recommend going ahead and reserving the enclosing /64 so that when you discover /120 wasn't the best idea, you can easily retrofit. The problem isn't silly, I didn't find it all that funny when I first induced it in the lab. Owen On Nov 1, 2012, at 12:58 , David Miller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/1/2012 1:59 PM, valdis.kletni...@vt.edu wrote: On Thu, 01 Nov 2012 14:28:48 +0100, "Miquel van Smoorenburg" said: We use a /120 subnet for servers to prevent the NDP cache exhaustion attack. We do maintain a mapping between IPv4 and IPv6 addresses; it's simply 2001:db8:vv:ww::xx, where xx is the hex value of the last octet of the IPv4 address. ooh.. that's a clever approach I hadn't seen before. Who should we credit for this one? /120 works well until you get > 99 (if you want the decimal representations of addresses to look the same)... or if your techs understand hex. 10.0.0.123 <-> 2001:db8:vv:ww::7b I have used /116 in the past. This gives you 1-fff at the end. 10.0.0.123 <-> 2001:db8:vv:ww::123 Hopefully, this is future proof(ish) in that IPv6 only hosts (...when that happens...) on the same subnet can use 2001:db8:vv:ww::[a-f][0-f][0-f] without danger of collisions with IPv4/IPv6 hosts. - -DMM -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQktR2AAoJECp6zT7OFmGauBMH/2bntbEMqdTtwPc/kMKAeikc iHd3giEcstp/v5kaAgdZGm68Juy3jlHXVe7TZriQA3OWYI7dSzZhuVFQxwP2+t1t fsZiU1ptoSKJMnQZhUdCOSuDXQZ4IwAWyhLq1EoXNxwGWXbM+KpddfwHtfLG6syz 3RQ2BB48l+eT1fvxzd1xmyIAjOxvtsqmpLTTOmXAXtN7+e0py/VpoBvgaDfg3Xnt dnc80i2bKM+DGqZJyGbkno0lANh1iZRnUWaPethlxhgQA433Yzu06ut6Vq4zIN2k HZ84b7VbXbxrOmfiRca0vLgue/VyB6PlBevb9yVnqaHb3iWQKF0G8Mq1Ge/nm5I= =KSjA -END PGP SIGNATURE-
Re: IPv6 Netowrk Device Numbering BP
On Nov 3, 2012, at 04:19 , Tore Anderson wrote: > * Owen DeLong > >> On Nov 2, 2012, at 02:52 , Tore Anderson >> wrote: >> >>> It absolutely does make sense, especially in the case of IPv4/IPv6 >>> translation. For example, when using NAT64, "64:ff9b::192.0.2.33" >>> is an example of a valid IPv6 address that maps to 192.0.2.33. >>> Much easier to relate to for a human than "64:ff9b::c000:221" is. >> >> But there are two situations where you'd use that for NAT64... >> >> 1. Presentation of electronic information to the end user, where >> it's virtually impossible for the system to know whether that's a >> NAT64 address representing an IPv4 remote end or an IPv6 address, so, >> how do you know when to represent it that way to the end user? >> >> 2. As a destination specifier (in which case the system most likely >> got the address as a binary return from DNS64 and doesn't present it >> to the end user prior to sending the request off to the remote >> server and even if it did, again, doesn't likely have a way to know >> when to use that notation. > > There's also the case of when including NAT64 support directly into an > application. Not all applications use DNS, and therefore cannot use > DNS64 either, e.g., applications that are passing around IP literals in > their payload (p2p stuff like BitTorrent and Skype comes to mind). > However, by discovering the NAT64 prefix in some other way (see > draft-ietf-behave-nat64-discovery-heuristic), they can construct a > usable destination specifier by simple string concatenation. It's > wouldn't be the only way to do it, but it's certainly simple and easy to > understand approach. > But if the application is doing the construction, then it's doing it with binary and not with a string representation of the address. The binary 128 bits don't change. We're talking about the format of a string representing those 128 bit. >> Sure, there's the third possibility that an end-user is hand-typing >> an IPv6-encoded IPv4 address to go through a translator, but, I >> think for a variety of reasons, that behavior should be relatively >> strongly discouraged, no? > > That wouldn't be a end-user friendly application, no. However, for > network operators, dealing with IP literals is common when debugging or > other stuff. I frequently use the dotted quad syntax when working on our > NAT64 installation, and find it very convenient. > Fair point. >>> Similarly, when using SIIT, the same syntax may be used in firewall >>> rules or ACLs. So if you want to open, say, the SSH port from a >>> trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway >>> to your IPv6 server, it's much easier to open for >>> "64:ff9b::192.0.2.33", and it will also make your ACL much more >>> readable to the next guy that comes along than if you had used >>> "64:ff9b::c000:221". >> >> SIIT is a really bad idea. > > I disagree. In my opinion, SIIT is perfectly suited for data centres. > But let's not take that discussion here - I'll be submitting a draft > about the use case to the IETF in a few days, and I hope you'll read it > and participate in the discussion on the v6ops or sunset4 list (not yet > sure which one it'll be). What do you get from SIIT that you don't get from dual stack in a datacenter? > >>> Also see RFC 6052 section 2.4. >> >> RFC's contain all kinds of embodiments and documentation of bad >> ideas that should have been deprecated long ago. > > Certainly. There is, however, a mechanism for deprecating RFCs. Either > you can move them to Historic status, or you can obsolete them by > writing new ones. You, or anyone else who don't like the ::0.0.0.0 > syntax, is free to do so. Until that happens, though, it will remain > part of the standard and you cannot reject it out of hand just because > you don't like it. Fair point, however, I can certainly discourage its use. Frankly, lots of stuff from RFCs gets rejected out of hand by various implementers all the time. Owen
Re: Dark fiber usage info request - know-how pointers and experience sharing
Thank you all who answered. I got a few good leads to follow, and information on operation gotchas. ***Stefan
Re: IPv6 Netowrk Device Numbering BP
* Owen DeLong > On Nov 2, 2012, at 02:52 , Tore Anderson > wrote: > >> It absolutely does make sense, especially in the case of IPv4/IPv6 >> translation. For example, when using NAT64, "64:ff9b::192.0.2.33" >> is an example of a valid IPv6 address that maps to 192.0.2.33. >> Much easier to relate to for a human than "64:ff9b::c000:221" is. > > But there are two situations where you'd use that for NAT64... > > 1.Presentation of electronic information to the end user, where > it's virtually impossible for the system to know whether that's a > NAT64 address representing an IPv4 remote end or an IPv6 address, so, > how do you know when to represent it that way to the end user? > > 2.As a destination specifier (in which case the system most likely > got the address as a binary return from DNS64 and doesn't present it > to the end user prior to sending the request off to the remote > server and even if it did, again, doesn't likely have a way to know > when to use that notation. There's also the case of when including NAT64 support directly into an application. Not all applications use DNS, and therefore cannot use DNS64 either, e.g., applications that are passing around IP literals in their payload (p2p stuff like BitTorrent and Skype comes to mind). However, by discovering the NAT64 prefix in some other way (see draft-ietf-behave-nat64-discovery-heuristic), they can construct a usable destination specifier by simple string concatenation. It's wouldn't be the only way to do it, but it's certainly simple and easy to understand approach. > Sure, there's the third possibility that an end-user is hand-typing > an IPv6-encoded IPv4 address to go through a translator, but, I > think for a variety of reasons, that behavior should be relatively > strongly discouraged, no? That wouldn't be a end-user friendly application, no. However, for network operators, dealing with IP literals is common when debugging or other stuff. I frequently use the dotted quad syntax when working on our NAT64 installation, and find it very convenient. >> Similarly, when using SIIT, the same syntax may be used in firewall >> rules or ACLs. So if you want to open, say, the SSH port from a >> trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway >> to your IPv6 server, it's much easier to open for >> "64:ff9b::192.0.2.33", and it will also make your ACL much more >> readable to the next guy that comes along than if you had used >> "64:ff9b::c000:221". > > SIIT is a really bad idea. I disagree. In my opinion, SIIT is perfectly suited for data centres. But let's not take that discussion here - I'll be submitting a draft about the use case to the IETF in a few days, and I hope you'll read it and participate in the discussion on the v6ops or sunset4 list (not yet sure which one it'll be). >> Also see RFC 6052 section 2.4. > > RFC's contain all kinds of embodiments and documentation of bad > ideas that should have been deprecated long ago. Certainly. There is, however, a mechanism for deprecating RFCs. Either you can move them to Historic status, or you can obsolete them by writing new ones. You, or anyone else who don't like the ::0.0.0.0 syntax, is free to do so. Until that happens, though, it will remain part of the standard and you cannot reject it out of hand just because you don't like it. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: qwest.net dropping packets... wife would like someone to pick them up please...
> one router along the path showing loss that does not continue to > affect the rest of the path simply means the cpu on that router > is a bit too busy to respond to icmp messages trivial footnote: some folk configure some routers to rate limit icmp randy
