Re: Request to Publish ISATAP

[itojun@iijlab.net]

	on process details, i guess Margaret have answered.

>> 	in 5.1, the document proposes a different handling of link-layer
>> 	address option in ND from the normal ND.
>This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph
>on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the
>normative text that allows what ISATAP is doing is plain for all to see.

	i don't think RFC2461 section 7.2.2 permits modification to link-layer
	address option handling in ISATAP.  it only talks about the intended
	behavior of a node, like:
	- if dst = solicited-node multicast address, link-layer address option
	  MUST be present
	- otherwise, it SHOULD be present
	- for unicast solicitation an implementation MAY omit it

	ISATAP, on the other hand, defines a new handling rule for link-layer
	address option in the very last paragraph of 5.1.  it does not seem
	to me a permissible thing to do.

>>       also in 5.2, the document
>> 	proposes special handling of router discovery.  ND and router discovery
>> 	have to be link-layer independent, and if we wish to make any changes
>> 	to ND/autoconf, we must update RFC2461/2462, in link-layer independent
>> 	manner.
>Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1,
>we have the following text:
>   However, because ND uses link-layer multicast for some of its
>   services, it is possible that on some link types (e.g., NBMA links)
>   alternative protocols or mechanisms to implement those services will
>   be specified (in the appropriate document covering the operation of
>   IP over a particular link type).
>Clearly, no updates to RFC2461 are necessary since ISATAP is exactly
>such "the appropriate document..." as described above.

	the text right after the above-quoted part suggests me that "ND over
	NBMA is an area for further study".  it suggests me the need to define
	"ND over NBMA", in a link-layer independent manner.  the text does not
	permit you to define a new link-layer address option handling in ISATAP
	document.

	i guess IPv6 wg needs to provide "ND over NBMA" document, then ISATAP
	has to follow the ND sending/receiving rules in "ND over NBMA" document.

>> 	in 5.1, paragraph 2, what does "enhanced address resolution" mean?
>> 	is it documented in ISATAP document?  if so, where?
>This refers to the text exactly one sentence earlier, which says:
>   ISATAP hosts SHOULD enhance the static address resolution computation
>   with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA)
>So, "simple address resolution" = static computation with no neighbor
>discovery exchange, and "enhanced address resolution" = static computation
>plus a unicast NS/NA exchange. How clear do we need to be?

	you did not define "enhanced address resolution" in the text.  you
	should define a term whenever it is used for the first time in the
	document.  otherwise the reference "enhanced address resolution"
	becomes ambiguous to readers.
 
>> 	it is proposed that router discovery mechanism (near 5.2, find "PRL"
>> 	for Potential Router List) would use DNS for discovering ISATAP router.
> 	it creates circular dependency between link layer (ISATAP) and DNS.
>> 	the use of DNS must be dropped from the router discovery mechanism.
>
>Yes, DNS is one alternative for discovering the ISATAP router - but
>not the only one. Even so, the sequence a dual-stack node can use
>the following bootstrapping procedure:
>
>  - discover IPv4 address; DNS server
>  - configure the IPv4 stack
>  - wait for a while for native IPv6 RAs to arrive
>  - if no native v6 service:
>    - discover a domain name for the ISATAP service
>    - resolve the name into a list of IPv4 addresses
>      by name service lookup (could be DNS, could be
>      static file, ec.)
>
>Can you explain to me a scenario in which this would *not* work?

	if you assume the above scenario, the above bootstrap process should
	be documented (i.e. IPv4 DNS server must be known to the ISATAP node
	via DHCPv4 or whatever, before ISATAP router discovery process gets
	started).

	even with the above, once you discover IPv6 DNS server via DHCPv6-
	over-ISATAP or whatever, you create a circular dependency between link
	layer and DNS.  circular dependency is bad as it could put your stack
	into deadlock situation (it would like to send DNS traffic out for
	"isatap.example.com" but it can't), and worse, could be used by
	malicious party to put your stack into deadlock situation.

	therefore, i strongry recommend dropping ISATAP router discovery using
	DNS.

>> 	ISATAP router is a choke point wrt scalability of the mechanism
>> 	(for instance, link speed of ISATAP router would be the bottleneck for
>> 	all of the nodes in an ISATAP-based site).
>> 	we might be able to achieve some level of load-balancing using
>> 	coordinated advertisement of ISATAP router via PRL announcement,
>> 	however, it is not enough.
>
>Talk about unsubsantiated opinions! This statement would have been
>like the founding architects saying: "packet switching networks can
>incur congestion in some cases, so let's not even bother building them".
>Clearly, there is a need for better understanding of ISATAP's scaling
>properties - but, that's what experiments are for!

	but what you have asked for was a standard-track publication, not
	experimental.  and the scaling property of ISATAP i observed from
	the document has problem (even without experiment), as i stated above.

>BTW, my belief is that the ISATAP scaling question is a non-issue.
>Even if a site administrator felt the need to strategically deploy
>equipment for fault tolerance, load balancing, etc. the specification
>provides abundat flexibility to support this. It is left to implementors
>to create robust products to satisfy the anticipated needs of customers;
>the ISATAP specification has no business meddling in implementation
>details.  
 
	i tend to disagree - if there's obvious choke point in a
	specification we need to diagnose, we need to update specification,
	suggest operational workaround, or do whatever needed, to avoid that
	choke point.

>> 	i can't really parse section 7 paragraph 2.  what does it mean?
>> >   Appendix B proposes a specification for managing the IEEE OUI
>> >   assigned to IANA for EUI-64 interface identifier construction.  This
>> >   specification is made freely available to IANA for any purpose they
>> >   may find useful.
>Let me recommend that you give it 1-2 more re-reads, then skip ahead to
>Appendix B. The meaning is there, and the words (while not optimal) seem
>adequate to me. If you are still confused, let me assure you this text
>has absolutely no operational bearing on the rest of the specification. 

	I of course read appendix B.  what i don't understand is "this
	specification is made freely available to IANA..." part.  what is
	meant by "freely"?  free of charge?  freedom of use?  free from IPR
	issues?  what kind of control IANA would like to have over the
	EUI64 creation process in ISATAP document?   i still don't understand
	what you are trying to mean.

itojun