[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AD review of draft-thaler-v6ops-teredo-extensions (part 1)

I am reviewing this document, and even though the review is not complete yet, I decided to post the comments that I have so far. I have reviewed roughly until page 17. I will continue reading the document tomorrow. 

Technical:


Nonce: A time-variant counter used in the connection setup phase to
prevent message replay and other types of attacks.
Nonces are typically defined as time-variant random values or values used only once. A counter may be sufficient for this, but was this really what you meant? The document says later: 

  When a Teredo client sends an
  indirect bubble, it MUST generate a random 4-byte value, and include
  it in the Nonce field of a Nonce Trailer (section 2.2.1) appended to
  the indirect bubble, and also store it in the Nonce Sent field of its
  Peer Entry for that Teredo peer.
which seems to indicate you really did mean a random value. I think it is important in this application that others are unable to guess it. 


Teredo Client: A node that has access to the IPv4 Internet and wants
to gain access to the IPv6 Internet.
... using the Teredo protocol? (Otherwise, there are plenty of Teredo devices in the world according to this definition...) 

Editorial:

Idnits reports:


  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 15 instances of too long lines in the document, the longest
     one being 3 characters in excess of 72.


These should be corrected.


  == There are 6 instances of lines with non-RFC3330-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.
The document does seem to be using non-RFC3330 addresses as examples, 207.x.x.x and 157.x.x.x and maybe others. Please change them. (AFAICT, the use of IPv6 and private addresses is correct in the document, however, despite warnings from idnits.) 


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.) -- however,
     there's a paragraph with a matching beginning. Boilerplate error?


You may want to check this.


  == Missing Reference: 'RFC 4380' is mentioned on line 962, but not defined


Section 5.1.1 gets the reference identifier wrong (it has an extra space).


  -- Obsolete informational reference (is this intentional?): RFC 2463
     (Obsoleted by RFC 4443

It seems that the new RFC should be used instead, AFAICT.

Jari