RE: draft-huitema-v6ops-teredo-03.txt

["Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>]

Hi Margaret, Christian,

The issues I raised have been addressed in the new version to the extend
that the text in section 5.4 now seems complete.

Based on the assumption that "there is no trusted entry" in 2) and 3) of Section 5.4
means: "there exists no valid entry OR there exists an un-trusted valid entry".
I do have one follow-up question however:

 The Teredo Relay in some aspects compares to a standard last hop IPv6 router 
 and the list of recent Teredo peers
 (as well as the operational procedures in this respect)
 in many aspect compares to the Neighbour Cache and the NUD operation 
 that should be maintained by such a router.

 Routers send Destination Unreachable back to origin when address resolution fails, which may be
 performed by the router whenever a NC entry doesn't exists (initially or after
 the time out and consequent erase of a NC entry) 

 Assuming that we are in the situation where no valid Teredo peer entry exists, then here it seems:

 i) In case 2) a peer entry in trusted state is created without confirming the reachability of the peer. 

 ii) Reachability of the peer is verified while the packet is queued. When "unreachable" no entry is created/
     existing entries are deleted.

 I may understand the difference in between these two cases from the Teredo perspective, i.e.,
 cone NAT or not. The question I would like to raise is to what extend we are concerned 
 with trying to emulate the NUD based black hole detection performed
 by standard last hop routers - Were we to be very concerned with that then, as I think 
 Christian has pointed out on the list at some point, it could make sense for a Teredo Relay:

 2a) In case of no valid entry and cone NAT (Case 2):
  To queue packets while rechability is being verified. Do not create entry and 
  Send back Destination Unreachable when reachability cannot be ascertained.

 3a) (Case 3): Send back Destination Unreachable when reachability cannot be ascertained.

 Even, if we do not want to mandate (SHOULD) the above behaviour, I wonder whether it wouldn't
 be valuable to add some text discussing this.

 Additionally but somewhat similar, then I wonder how the "silently discard" in the last paragraph of Section 5.4.2
 compares with the standard Ipv6 redirect behaviour.

 BR, Karen
 
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> Sent: Sunday, December 05, 2004 4:47 PM
> To: ericlklein@softhome.net; henrik@levkowetz.com; Karen E. Nielsen
> (AH/LMD); Francis.Dupont@enst-bretagne.fr;
> Markku.Ala-Vannesluoma@nokia.com; Jonathan Rosenberg
> Cc: v6ops@ops.ietf.org
> Subject: draft-huitema-v6ops-teredo-03.txt
> 
> 
> 
> Hi Eric, Henrik, Karen, Francis, Markku and Jonathan,
> 
> There is a new version of the Teredo draft available at:
> 
> http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt
> 
> Could you check whether this version addresses the issues that you 
> raised during IETF LC?  It would be best if you could review this 
> document and return any feedback by this Thursday, 9-Dec-04.
> 
> If there are no further objections, I will place this draft on the 
> IESG agenda for consideration on our 16-Dec-04 telechat.
> 
> Thanks!
> 
> Margaret
>