Subject: draft-ietf-zeroconf-reqts-12.txt

From: Aidan Williams <[email-masked]>
Date: Wed, 09 Oct 2002 11:35:25 +1000

I didn't see an email on the ietf announce list, but a new
version of the requirements draft has been available for a
little while now:
   http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-12.txt

This document contains all the changes that have been discussed
on the list in recent times.

-- 

regards
	aidan
____
:wq!

Sydney Network Research Lab             [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://marc.labs.mot.com/snrl/

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 8 Oct 2002 20:54:48 -0500

----- Original Message ----- 
From: "Aidan Williams" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 08, 2002 8:35 PM
Subject: draft-ietf-zeroconf-reqts-12.txt

> on the list in recent times.

Your often repeated use of the term "IP address" may be more precisely articulated
with the term, "32-bit IP address", and to be completely precise, it should also note
that you are assuming TOS=0x00,0x*0, or 0x0*, which is a 4-bit extension to the
32-bit IP address, for a total of 36-bits, when people do TOS Routing. As noted
below, people are making the assumption that when they say IP address, that it is
32-bits. That is not the case with all of the software (especially Linux software) which
can consider all 160-bits in the IPv4++ Header for Routing purposes.
http://www.netfilter.org

=====
http://www.merit.edu/mail.archives/nanog/msg04234.html
From: Paul Vixie
note that c-root's network operator has offered to filter RFC1918 on
input from other AS's, but it's actually useful to keep on measuring it.)
http://www.merit.edu/mail.archives/nanog/msg04258.html
From: Sean Donelan 
http://www.ipservices.att.com/backbone/techspecs.cfm
  AT&T has also implemented security features directly into the backbone.
   IP Source Address Assurance is implemented at every customer
   point-of-entry to guard against hackers. AT&T examines the source
   address of every inbound packet coming from customer connections to
   ensure it matches the IP address we expect to see on that packet. This
   means that the AT&T IP Backbone is RFC2267-compliant.
====================================================

With 128-bit DNS, one has to look at MORE than the 32-bit address fields.
The so-called RFC 1918 address spaces only apply in the TOS=0,0x*0, and 0x0* cases.
With 2,048 address spaces that can have a 10.*.*.* address block, some of them
may make sense. While AT&T may choose to filter/block all such traffic, customers should
know that and consider using other networks, that pass all 160-bits end-to-end,
or make sure they are routing around blockades via wireless and other mediums.

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

As for the traffic coming to the "toy", legacy, 32-bit DNS root servers. It is not
surprising that they are apparently not up to date on the latest technology. Also,
it is interesting that bogus traffic is apparently used to claim they are overloaded.
That arguement is of course used to claim that only a limited number of TLD slots
are available. While everyone knows the arguments are pure FUD, it is good to
see it confirmed that any basis for the claim is based on bogus traffic which would
not normally reach up-to-date equipment. Fortunately, less and less people use the
aging legacy root servers, they can locate the TLD clusters directly and route to them.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Oct 2002 11:52:30 -0400

> on the list in recent times.

Thanks Aidan. I'm putting this docuemnt on the IESG agenda for
discussion during next week's IESG telechat.

In looking at the new text, I'm not sure that Section 3.2.2 is quite
right.

Specifically, it's not so clear to me that "close coupling" and "API
compatible" are that different from each other. Seems like they are
really the same, except maybe that the latter is even more general
(i.e, many name services vs. just zeroconf and DNS).

For example, the document says:

   Again, there is increased risk of spoofed responses if the multicast
   zeroconf name resolution protocol is used to resolve
   "www.someco.com".  One possible way of minimising the security risk
   is to ensure that locally scoped names are distinguishable from DNS
   names, perhaps via a known reserved DNS suffix or by virtue of not
   containing a dot.  A multicast zeroconf resolution protocol could
   then avoid making requests for names which look like global DNS
   names.  Alternatively, we could require that zeroconf name lookups
   only be performed when the equivalent DNS lookup has failed.

single labels (without dots) are part of the normal API. So I don't
see how dot-less names could somehow be safely considered non-DNS.

Thomas