IEPG Meeting, Sunday July 14, 10am onward<p>

<i>(Caution: my notes, my typos, my intepretations! - Geoff Huston)</i><p>

<hr>
Jun Murai<br>
Summary of the Internet Car Testbeds<p>
<blockquote>
This effort is a Keio University / WIDE research project as a showcase of Internet technologies with mobile IPv6 networking. The project's objectives are to demonstrate the potential role of the Internet in other industry sectors, in this case the automotive industry and in various applications that relate to vehicle traffic control.<p>

The project's assumed environment for Internet-enabled cars is a mix of 802.11, cellular infrastructure and Dedicated Short Range Communications (DSRC) for hot points (such as toll both local radio). The target is a sea,less IP environment as the car roams across these connectivity environments.<p>

There are 3 connectivity models that were evulated within the scope of the project: the single in-vehicle computer, an in-vehicle routers with multiple LAN devices in the car (possibly envisaging the the car's wiring loom as a LAN with multiple sensors and devices attached), and the multi-router model in the car (a more complex model with internal router and a external mobile router). (The multi-router model is currently under development.) <i>I like the diagram of a lan-connected car key in the presentation!</i><p>

The current project runs about 60 cars in the Yokohama area.<p>

The single computer model assumes each device roams in the mobile network independantly. This uses mobile IPv6 with some extensions and some effort to undertake route optimization. The project evaluated a potential tunnelling solution, but this was avoided in favour of  full implementaion using mobile IPv6.<p>

In matching the various car models to the mobility model, the mobility aspects include consideration of the differences between mobile host vs mobile network.<p>

Interface management uses an "Interface management" model to control dyanmic V6 tunnelling over the available transports. There is a layer 2 trigger mechanism for the V6 tunnel interface manager to select the "best" available V4 transport interface (best is a price / quality algorithm). The interface management system also suports native V6 over 802.11 with integrated L2 signalling back to the interface manager.</p>

Dedicated Short Range Communication (DSRC) - the traffic management sector is attempting to use 5Ghz as the carrier frequency, as is 802.11. There is work on developing IP over PPP over DSRC and also an Ethernet-type broadcast DSRC.</p?

There have been two project testbeds:  IPCar, 270 cars in the Yokohama region (<a href="http://www.ipcar.org">www.IPCar.org</a>), which has a web interface that can probe traffic and weather information as a live update from the cars, and InternetITS (InternetITS.org), that used 1570 cars in a Nagoya testbed.<p>

Applications suggested include monitoring for congested streets with live updates as a cheaper method than using in-road sensor systems. Also signalling the car's windscreen wiper activity rate and the current location back to a collector to indicate wet weather. For taxis, incidence of local showers can be used to show likely concentrations of passengers.</p>

There is some potential for further work on the minimum number of cars (sample points) to obtain reliable environmental information.</p>
</blockquote>
<hr>
Anne Lord<br>
RIR Update<p>
<blockquote>
RIR Coordination:<ul>
<li>New IPv6 policy implemented on 1 July (Ripe and APNIC) and coming month (ARIN)
<li>registration transfer project - to transfer historic allocations to the appropriate "home" RIR, coordination and documentation underway
<li>Staff exchange between RIRs
</ul><p>
Outreach:<ul>
<li>Presentation on RIR industry self-regulatory profile to various industry sectors and bodies
<li>coordinated training efforts</ul><p>
Emerging RIR support:<ul>
<li>LACNIC - working transition with ARIN
<li>AFRINIC - woring transition with RIPE</ul><p>
ASO:<ul>
<li>Secretariat moves to APNIC for 2003
<li>ASO GA to be hosted by ARIN in 2003</ul><p>
Open Policy meetings<ul>
<li>APNIC Japan Sept
<li>ARIN (+NANOG) Oregon Oct
<li>RIPE Greece  Sept</ul><p>
IPv4<ul>
<li>unallocated pool is at 37% of the total address space
<li>note reducing allocation rate in 2002 compared to 1999 - 2001 trends
<li>by country breakdown shows JP, CN, KR US and AU as the largest national domains for allocations</ul><p>
AS<ul>
<li>ARIN greatest in 2002
<li>AS assignments also shows a decreasing rate</ul><p>
IPv6 allocations<ul>
<li>APNIC and RIPE have allocated 125 blocks - ARIN has allocated 29 historically
<li>2002 shows continued growth
<li>by country: JP, US, DE and KR as largest national entities</ul><p>
APNIC<ul>
<li>whois v3 migration (Mid August) test at v3.whois.net
<li>irr at <a href="http://irr.apnic.net">irr.apnic.net</a> and will migrate to the whois db
<li>delegations v6 /21 and v4 221/8
<li>MyAPNIC integrated frontend <a href="http://myapnic.net">myapnic.net</a></ul><p>
 ARIN<ul>
<li>new DB to be released in Aug with training underway
<li>LACNIC transition support - final apporval of LACNIC antipcated in November 2002</ul><p>
RIPE<ul>
<li>V6 /23
<li>new V4 policy documentation
<li>secure member service web portal undcer development
<li>RIPE NCC Member survey being conducted
<li>RIPE RIS has a US presence at MAE-WEST
<li>phased out Mail-Fropm to MD5-PW authentations
<li>routing registry full prototype and IRR toolset developed - plans include reporting and interface enhancements</ul><p>
  	</blockquote>
<hr>
Henk Uijterwaal<br>
EBONE Postmortem<p>
<blockquote>
  A look at the effects of the EBONE shutdown. <p>
  Background of a KPNQWEST build.<p>
  First shutdown commencing July 2 (EBONE), with next major shutdown planned for July 19<p>
  Used RIPE NCC one-way delay loss measurement network. Some 2000 paths had some EBONE implications<p>
  Use of TTM alarms for long and short term average deviation:<ul>
   <li> The TTM alarms rose from a daily average of 400/day to ~650 on July 2
    <li>The RIPE hourly data shows the work progres of the shutdown</ul><p>
  Look of individual paths for connection loss and rerouting<ul>
  	<li>some identication of path loss in the data for some single-homed EBONE downstream nets
  	<li>some identification of re-routing with subsequent re-engineering to a stable path
	<li>identification of restoration to longer latency paths
  	<li>visibility of restoration to lower capacity switching equipment with higher loss and jitter due to overload on the switching infrastructure
  	<li>use of a superior backup path</ul><p>
  Summary - the internet surivived quite comfortably, with some assertion that it is not as good as before (although the mapping of volume to paths is not availble)<p>
</blockquote>
<hr>
Akiro Kato<br>
JPNIC DNS misconfiguration<p>
<blockquote>
  Observation of may unanswered DNS queries and 8.2.3 bug for lame delegation being exercised<p>
  The question is wether the DNS is being operated correctly - or how much is bad out there!<p>
  JPNIC set up a DNSQC TF intended to improve the DNS quality<ul>
  	<li>active monitoring and active messaging on errors
  	<li>passive diagnosis to allow others to check their DNS configs</ul>
  JP has about 370,00 delegations with 800000 NS records in the .jp domain, with 2.16 NS records per delegation.
  This is scatteres across 72,000 DNS servicers.
  Initial survey conducted June 14 - 18 2002, using dig queries for:<ul>
  	<li>DNS server version
  	<li>lame delegation
  	<li>consistency on NS record set</ul><p>
     Of the 72,000 servers:<ul>
     	<li>5% had non resolvable names (no IP addresses)
     	<li>12% of the servers were not accessible</ul><p>
     Of the 800,000 NS records:<ul>
     	<li>16.1% were lame
     	<li>33% of .jp domain were lame (recent delegations)
     	<li>10% of the hierarchical .jp domains (ac.jp etc) were lame
     	<li>only 65.5% of the NS sets were consistent</ul><p>
  More testing of SOA vals, NS pointing to CNAME, etc being considered<p>
</blockquote>
<hr>
George Michaelson<br>
More bad DNS<p>
<blockquote>
  Scan if in-addr.apra in the APNIC zones
  for 97 days<p>Found that an average of 20% to 30% have problems:<ul><li>one or more NS not visible
  	<li>SOA mismatch</ul>
  for 97 days:<ul><li>10% - 15% are fully lame
		(no functional NS)</ul>
  across the sample period:<ul><li>33% of the domains are always viaible
  	<li>43% are 99% available
  	<li>11% are fully lame for the entire period
  	<li>18% had intermittently lame</ul>
  (note - only one probe point and routing inconsistencies may impact this number.)<p>

  fully lame is flat lined across the period<p>
  partially lame values show higher levels of change day by day.<p>

  Histogram of lameness shows that there is a strong clustering of fully lame and slightly lame - no real incidence of 50% lameness over the measurement period.<p>

  Propose to nag-enable the in-arpa delegations.
  More consideration about what to do with persistent lame delegations (disable?)<p>
</blockquote>
<hr>
Nevil Brownlee (for Andre Broido)<br>
Analysis of RFC 1918 zones<p>
<blockquote>
Presentation of work undertaken by Andre Broido. There is leakage of RFC1918 spaces with requests to the root servers referencing 1918 address space (_rfc1918_.in-addr.arpa)<p>

Over 1M hosts sending messages attempting to update private address records.<p>

Illustration of diurnal patterns with strong peaks at clock hour ticks in each local timezone (3 US, 2 EUR, 3 Asia)<p>

Guessing that large sites are not generating these updates, and instead these are smaller sites that appears to be business related (low weekend levels) that are not adequately managed at the firewall / net interface level for trapping out such bogus DNS requests.<p>
</blockquote>
<hr>
Ed Lewis<br>
DNS Lameness<p>
  <blockquote>
Lameness is defined as<ul>
<li>a NS domain name server name that has no glue / IP address OR
 <li>does not respond to DNS queries (greyer) OR
  <li>responds with negative no such domain</ul>
  MIGHT be lame when a server has multi IP addresses only some of which respond.
  MIGHT be lame when non-authoritative (i.e. recursive) response.<p>

  This effort is targetted at ARIN reverse map delegations.<p>

  Survey results:<ul>
    	<li>servers / zone avg 2.37
    	<li>addrs per zone avg 2.32
    	<li>zones with NO IP addrs 3,000
    	<li>zones with 1 IP addr 7,300</ul>

  Some servers have both good and lame zones.<p>
  16% of all the zone servers are non-responsive for all zones.<p>

30% of servers just not working is pretty consistent with other studies of DNS Lameness<p>

The test code takes some 11 hours to run! (has to ask every server for every zone) UDP congestion control would help!<p>

</blockquote>
<hr>
Phil Smith<br>
Internet Routing Table Update<p>
<blockquote>
Changes: <ul>
 <li>search for 192/8 space for unassigned addresses (working on a more accurate answer of the size of the unallocated pool)
 <li>count of advertised prefixes that are smaller than actual registry allocations cleaned up
 <li>unique prefixes
  <li>maximal aggregation analysis
  </ul>

  For the reports, see <a href="http://www.apnic.net/stats/bgp">www.apnic.net/stats/bgp</a>.<p>

 <i>(<a href="http://bgp.potaroo.net">bgp.potaroo.net</a> also has a set of reports on this,including analysis of route-views data)</i><p>
</blockquote>
<hr>
Dave Meyer<br>
The IP Carrier Space<p>
<blockquote>
A look at the growing level of complexity within Internet Platforms and its implications (draft-ymbk-draft-guidelines-00.txt)<p>

The argument is that complexity is the primary input that impedes scaling and generates additional overhead.<p>

The principles used here are amplification and coupling to suggest that large scale complex systems are detrimental to quality outcomes and that system reliability and scaleability are not natural outcomes of excessive complexity and single-minded attention limited exclusively to component reliability.<p>
</blockquote>