Subject: [Hipsec] HIP base draft - pre 19.10.2005

From: Petri Jokela <[email-masked]>
Date: Wed, 19 Oct 2005 15:56:32 +0300

Hi,

I uploaded a new version of the base draft to our server.

http://hip4inter.net/drafts.php

with txt, html, xml, and diff from the previous pre-version. The date is 
191005.

The main change was the HIP header modification according to SHIM6 as 
proposed earlier by Pekka.

I didn't give any reason in the text, why there are two fixed bits in 
the HIP header. Somehow I feel that something should be said. On the 
other hand it is vague to refer to SHIM6 work if they don't have 
anything on paper related to this new header structure. Comments?

/petri

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 19 Oct 2005 15:17:30 +0200

Thanks, Petri!

draft-ietf-ipsec-ikev2-algorithms-00  should be  -05

I *think* (please check) that RFC 2541 defines Blowfish CBC; it might  
be a better reference than [Schneier96].

draft-ietf-hip-arch-01 is now -03

I think some other drafts are also referring to old versions.

It would be *very* nice to have the state diagram as a PNG or SVG
in the HTML version...

Section 4.4.2 would definitely look better if it was recoded as a  
table, using the new table structure in xml2rfc.

For the fixed bits, I think it is sufficient to say "The two fixed  
bits in the header are reserved for potential SHIM6 compatibility   
[draft-ietf-shim6-proto-01].  For implementations adhering (only) to  
this specification, they MUST be set as shown when sending and MUST  
be ignored when receiving.  This is to ensure optimal forward  
compatibility.  Note that implementations that implement other  
compatible specifications in addition to this specification, the  
corresponding rules may well be different.  For example, in the case  
that the forthcoming SHIM6 protocol happens to be compatible with  
this specification, an implementation that implements both this  
specification and the SHIM6 protocol may need to check these bits in  
order to determine how to handle the packet."  Or something like that.

A table summarising the packet types would be nice somewhere in 5.3.

It *might* be wise to bump up the codes for packets types beyond R2  
to be greater than 16, in order to leave the space between 5 and 15  
for SHIM6.  Opinions?  Note that SHIM6 currently uses I1-R2 in a  
similar way to HIP, and I don't see any difficulty in sharing them.

There are probably other editorial nits, but other than that I think  
we start to be done.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Fri, 21 Oct 2005 16:14:56 +0300

I uploaded an edited version of the base draft:

The current version is dated 211005. See also comments below.

> be a better reference than [Schneier96].

I changed the reference to RFC2451.

> I think some other drafts are also referring to old versions.

The automatic reference update from resource.org seems not to work 
properly. They should be up-to-date now.

> It would be *very* nice to have the state diagram as a PNG or SVG

I noticed that the HTML version contains now a _very_optimized_ state 
diagram ;-) I'll update that next week.

> table, using the new table structure in xml2rfc.

I hope it is ok now. The xml2rfc table-system is not as flexible as I 
hoped. Texts and tables are now on "wrong" pages. I'll try to fix that 
on Monday. If somebody knows either how to put <preamble> to the left 
and not centered OR to somehow force <t> to be on the same page as 
following table, I would appreciate that information.

> For the fixed bits, I think it is sufficient to say ...

Added text.

> A table summarising the packet types would be nice somewhere in 5.3.

Added a table.

> It *might* be wise to bump up the codes for packets types beyond R2  to 
> be greater than 16, in order to leave the space between 5 and 15  for 
> SHIM6.  Opinions?  Note that SHIM6 currently uses I1-R2 in a  similar 
> way to HIP, and I don't see any difficulty in sharing them.

I changed the numbering. Please send comments on that! I can still edit 
it before IETF submission on Monday.

/petri