- RIPE DDoS (posted 2003-04-10)
(Distributed) Denial of Service attacks continue to be a serious problem. (Well, for the victims, at least.) RIPE
suffered an attack
on februari 27th 2003 that almost wiped them off the net for two and a half hours.
- Bogon filtering (posted 2003-04-10)
On august 7th 2002, Rob Thomas announced on his
bogon list and a number of mailinglists
that IANA
had delegated the 69.0.0.0/8 address block to APNIC
for further distribution to ISPs and end-user organizations in the Asia-Pacific region.
The next day, APNIC made an announcement of their own.
Exactly seven months later, someone who had gotten addresses in the new range posted a message to the
NANOG under the title "69/8...this sucks". He encountered problems
reaching certain destinations from the new addresses and wrote a script to test this. It turned out a significant
number of sites ("dozens") still filtered this range.
Further investigation uncovered that this wasn't so much a routing problem, but many firewall administrators
also use the bogon list to create filters. And then subsequently fail to keep those filters up to date.
This sucks indeed.
- Path MTU Discovery problems (posted 2003-05-19)
If your network has a link with an MTU that's smaller than 1500 bytes in the middle, you're in trouble. It's not the first time this came up on the NANOG list and it won't be the last.
In order to avoid wasting resources by either sending packets that are smaller than the maximum supported by the network or sending packets that are so large they must be fragmented, hosts implement Path MTU Discovery (PMTUD). By assuming a large packet size and simply transmitting them with the don't fragment (DF) bit set (in IPv4, in IPv6 DF is implied) and listening for ICMP messages that say the packet is too big, hosts can quickly determine the lowest Maximum Transmission Unit (MTU) that's in effect on a certain link.
Most of the time, that is. In RFC 1191 it is suggested that hosts quickly react to a changing path MTU. So implementors decided to simply set the DF bit on ALL packets. At the same time, many people are very suspicious of ICMP packets since they can be used in denial of service attacks or to uncover information about a network. So to be on the safe side a significant number of people filters all ICMP messages. Or routers are configured in such a way that the ICMP packet too big messages aren't generated or can't make it back to the source host. NAT really doesn't help in this regard either.
So what happens when all packets have DF set and there are no ICMP packet too big messages? Right: nothing. Since the first few packets in a session are typically small session get set up without problems but as soon as the data transfer starts the session times out. So what can we do?
-
The real solution would be that TCP implementators clean up their act and stop depending on ICMP messages that may or may not be generated somewhere along the way. Unfortunately, it looks like they think they don't have to do anything since:
-
People who configure firewalls and routers should make sure the ICMP packet too big messages are generated with correct IP addresses and passed along to the source host.
Unfortunately, this doesn't really solve the problem for a user who is behind some kind of tunneling mechanism that brings the MTU down below 1500 bytes, such as PPPoE, PPTP or GRE. Fortunately TCP has a Maximum Segment Size (MSS) option that is used to tell the other side the maximum size of the TCP segment (= without IP and TCP headers) it should send. When a host itself knows about the smaller MTU it adjusts the MSS so there is no problem. The trouble starts when there is a router connected to the network with the reduced MTU so the end hosts see the regular ethernet MTU. Many routers implement a feature where the MSS option in TCP session establishment packets is manipulated to avoid this problem. On Cisco routers this is a fairly recent feature that is enabled with the interface command ip tcp adjust-mss .... Unfortunately, it is not entirely clear what impact this feature has on fowarding performance.
RFC 2923 TCP Problems with Path MTU Discovery
The MSS Initiative
Cisco - Why Can't I Browse the Internet when Using a GRE Tunnel?
- IPv6 debate, better routing? (posted 2003-05-23)
Geoff Huston, member of the
Internet Architecture Board,
wrote as one of his monthly columns for the
Internet Society
Waiting for IP version 6.
In this column Geoff argues that the only real advantage IPv6 has over IPv4 are the larger
addresses, but we are not very close to running out of IPv4 address space yet with 1.5 billion
addresses still unallocated. So he expects demand for IPv6 will not be driven by anything or
anyone that's online now but rather by the tons of new devices that need connectivity in the future.
The IPv6 Forum doesn't quite agree and,
in the persons of Latif Ladid and Jim Bound, sent in a
response. They argue
IPv6 does have some additional features that make it better than IPv4, such as the flow label,
for which there is currently no use defined but it could help quality of service efforts, stateless
autoconfiguration and routing scalability. They do have a point here.
Sure, in IPv4 you can use DHCP and you're online without having to configure an address
and additional parameters. However, there must still be a DHCP server somewhere. These days,
DHCP servers are built in pretty much anything that can route IP or perform NAT. This works quite
well for numbering hosts that act as clients, but it doesn't really help with servers because in
order to have a DHCP server give out stable addresses it must be configured to do so. This is only
slightly better than having to configure the host itself. In IPv6, this is only a problem in
theory. IPv6 stateless autoconfiguration makes a host select the same address for itself each time,
without the need to configure this address either on the host or on a DHCP server. The theoretical
problem is that some other host may select the same address because of MAC address problems
(as the lower part of the address is derived from the MAC address) but this should be extremely rare.
Routing is the same for IPv6 as for IPv4. Both use provider aggregation to limit the number of routes
in the global routing table. However, address conservation in IPv4 makes it necessary to make these
provider blocks much smaller than is desirable from a routing aggregation standpoint. In IPv4, ISPs
get /20 blocks and only the ones using up address space really fast get /16 blocks. In IPv6, every ISP
gets at least a /32 and the next seven /32s remain unallocated so this can grow to a /29 (at least in
the RIPE region) so ISPs need far fewer individual blocks to assign address space to their customers.
This should help with route scaling. Unfortunately, it doesn't help with customers who are multihomed.
But that's another story.
- DoD to transition to IPv6 in 5 years starting october 2003 (posted 2003-06-15)
This friday the 13th (of june 2003), John Stenbit, assisten secretary of defense, announced that the US Department of Defense will start its transition to IPv6 this october. The DoD expects to be fully IPv6-capable by 2008. The reasons to switch to IPv6 are:
- better quality of service
- end-to-end security
- to keep in step with expected developments in the commercial internet
The transition is not driven by lack of IPv4 address space. However, there is no fundamental difference in QoS and security mechanisms between IPv6 and IPv4, apart from the flow label field in IPv6 for which there isn't really a use yet, so these are questionable reasons to move to IPv6. The DoD expects switching to IPv6 in the commercial internet (or at least significant parts thereof) to happen at a faster rate, so in order to keep up the DoD is taking a head start.
The DoD initiative was met with approval on the IETF discussion list, although some people remain sceptical as past announcements, such as the adoption of the ADA programming language or ISO CLNS didn't exactly pan out. Still, reading
the transcipt of the briefing the DoD seems to mean business by requiring all IP-capable hard- and software procured after october first to support IPv6.
(advertisement)
