Subject: [manet] I-D Action:draft-ietf-manet-iana-06.txt

From: [email-masked]
Date: Fri, 26 Oct 2007 00:30:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title           : IANA Allocations for Mobile Ad hoc Network (MANET) Protocols
	Author(s)       : I. Chakeres
	Filename        : draft-ietf-manet-iana-06.txt
	Pages           : 7
	Date            : 2007-10-26

This document enumerates several common IANA allocations for use by
MANET protocols.  The following well-known numbers are required: a
UDP port number, an IP protocol number, and a link-local multicast
group address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-06.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-manet-iana-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-iana-06.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 26 Oct 2007 10:22:53 +0530

I'd like to announce a revision of the IANA document. During IESG
review there were a number of comments/suggestions/questions raised,
and they have been addressed in the new revision.

First, the IESG was unclear on how our multiple protocols would
operate simultaneously using these assignments. To rectify this issue,
I have included a normative reference to PacketBB. That is, all
protocols using these IANA allocations must conform to PacketBB. Using
PacketBB and it's IANA type-space registries will ensure that
implementations are able to correctly identify information and
demultiplex any combined messaging.

Second, during IETF LC & IESG review there were a few questions asking
why we were not allocating an IP protocol number. In response to this
request, I have added a request for an IP protocol number. This will
allow us to advance our protocols from UDP to an IP protocol number in
the future.

Third, I have revised the IANA section to include specific actions for
IANA, as well as pointers back into the document. The instructions are
verbose, but will be removed upon publication.

Please review the updated document ASAP and provide any comments.

Thank you,
Ian Chakeres

On 10/26/07, [email-masked] <[email-masked]> wrote:
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Oct 2007 13:17:32 +0100

> Please review the updated document ASAP and provide any comments.

One minor nit, and one more significant comment.

The minor nit is that the reference [I-D.ietf-manet-packetbb] is
two versions out of date.

The significant comment is that this document says

    The security issues associated with using the same UDP
port/multicast
    address/IP protocol number for multiple protocols are addressed in
    [I-D.ietf-manet-packetbb].

No, it isn't, and neither should it be. The place for that discussion
is here, not in packetbb.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Oct 2007 13:57:20 -0700

I'm sorry I have not been following this one closely, but
the -02 version asked for site-scoped allocations for IPv4
and IPv6, and I no longer see those in this version.

There is at least one use case for a site-scoped IPv4
multicast address that I am aware of, so I would like to
see that allocation request put back in the document.

Fred
[email-masked]  

> -----Original Message-----
> From: Ian Chakeres [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 9:53 PM
> To: manet
> Subject: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt
> 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Oct 2007 14:20:51 -0700

> see that allocation request put back in the document.

Err, I meant to say for *both* IPv4 and IPv6.

Fred
[email-masked]

---

From: Thomas Clausen <[email-masked]>
Date: Fri, 26 Oct 2007 23:26:25 +0200

> is here, not in packetbb.

I agree with Chris, that this discussion does not belong in packetbb,  
and I feel that draft-ietf-manet-iana should not suggest this.
-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Oct 2007 23:47:26 +0200

> Err, I meant to say for *both* IPv4 and IPv6.

For IPv6, I am not sure what you mean by site-scoped _multicast_ 
addresses, since site-scoped fec0 addresses are deprecated.

If we can get a common understanding about what a site is in general, 
and what is a site in the case of a MANET - then I think I can agree.

Or am I the only one here to not understand what a site is.

Alex

> [email-masked]

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 26 Oct 2007 14:57:10 -0700

Alex,

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, October 26, 2007 2:47 PM
> To: Templin, Fred L
> Cc: Ian Chakeres; manet
> Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt
> 
> Templin, Fred L wrote:

Site-scoped multicast are cited in RFC4291 and have nothing
to do with the now-deprecated fec0 site-scoped unicast.

> Or am I the only one here to not understand what a site is.

I have a definition for site that I use, but I don't think
you are the only one who would claim not to understand site.
This discussion may apply to a larger scope than just this
wg, however. What do you think?

Fred

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 27 Oct 2007 18:15:18 +0530

Fred, Alex.

Please look back in the manet archives for discussion about
site-scoped multicast allocations. Many people were strongly against
including site-scoped multicast. The main reason was that none of the
current protocols being standardized utilize site-scoped messages.

I previously fought hard for site-scoped addresses, but I was in the minority.

Ian Chakeres

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Oct 2007 10:16:01 -0700

Ian,

Sorry for the delay; didn't see this until now. I also
missed the list archive discussion thread you're referring
to - I guess that was the one that took place ~5/10/07?

Based on what I saw in the archives, two frequent posters
to this list were saying to keep the allocations, one
frequent poster to the list was asking to remove them,
and two new posters to the list asked about the use case.
Were there other comments/opinions registered that didn't
show up on the list?

Fred

> Sent: Saturday, October 27, 2007 5:45 AM
> To: Templin, Fred L
> Cc: Alexandru Petrescu; manet

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 30 Oct 2007 18:20:26 +0100

> allow us to advance our protocols from UDP to an IP protocol number in
Teco:
1) I think this topic was discussed on MANET ML and the outcome was there
was no need for requesting an IP_PROTO number.
2) I do not like requesting an UDP port number AND an IP_PROTO number. A STD
protocol shall pick one and shall not leave this open to <undefined>.

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 31 Oct 2007 16:15:44 +0530

All our WG protocols currently use UDP, but several people have
expressed that in the future we might want to migrate the protocols to
use an IP protocol number.  I see these two options as complementary
and not necessarily competing.

Teco & everyone, do you have a strong preference to NOT allocate an
IP_PROTO number? I have added the IP_PROTO allocation on behalf of the
several parties (including an AD) who have expressed interest.

Thanks.
Ian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 12:11:54 -0000

> was no need for requesting an IP_PROTO number.

As I recall, it was the ADs who suggested this. Ian, is that correct?

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 31 Oct 2007 14:12:17 +0100

> several parties (including an AD) who have expressed interest.

I do NOT have any objections to requesting an IP_PROTO.

I am STRONGLY AGAINST not defining which transport is to be used for
"MANET".
I think using UDP is acceptable. In RFC2119 wording, MANET protocols SHOULD
use the "manet" UDP port and MANET protocols MAY use the "manet" IP
protocol.
When using the "manet" IP protocol, we have to add transport functionality
in packetbb that was provided by UDP. Especially the datagram Length and
Checksum fields in the UDP header shall have their replacements in packetbb
pkt-header. Packet length can be signaled in pkt-size. I cannot find
something for Checksum.
In the packetbb specification, it MUST be noted that the MANET protocol MUST
include and use the pkt-size and "pkt-checksum" fields when using native IP
as transport.
When adding a "pkt-checksum", we should discuss using a 32-bit field.

On allocation, we could request the TCP_PORT also, although today no one
needs it. Obviously, TCP is not a candidate for MANET; especially for the
multicast part of it. But maybe someone needs this in the future. (e.g.
ad-hoc BGP)

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 13:21:46 -0000

Just to be clear, I don't have any strong feelings about this
either way (UDP or native IP).

> pkt-header. Packet length can be signaled in pkt-size. I cannot find

If you need a checksum (which is a pretty crude form of error detection
code) at the network or transport layer then UDP will do. But there are
plenty of data link layers that do a much better job in this are, making
this a bit redundant at the transport layer.

> include and use the pkt-size and "pkt-checksum" fields when using
native IP

I do not agree with putting a checksum into packetbb. If you need
it, do it with UDP. You may not need it, even without UDP. And

> When adding a "pkt-checksum", we should discuss using a 32-bit field.

That's one very good reason why it doesn't belong in packetbb.
16 bits or 32? Checksum or CRC? Which generator polynomial?
Which way to shift?

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 31 Oct 2007 18:59:13 +0530

In the future when we specify operation using an IP_PROTO, we will
likely need some additional TLV-types to assist. For example, a
pkt-TLV-type for CRC or FEC. I do not think these need to go into the
PacketBB spec. They can be written in the future and normatively
reference PacketBB, like TimeTLV.

Ian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 13:35:56 -0000

I agree with Ian. When I said not in packetbb, I didn't
mean not in the packetbb structure, just not in the
packetbb base specification. In TLVs, very little is
not allowed. Although it would be good to find out how
much use the UDP checksum really is these days. In
practice is it essentially redundant based on link layer
error control, or is it still a valuable part of the IP
protocol stack? (I have no idea, but would find any data
on the subject interesting.)

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 31 October 2007 13:29
To: Dearlove, Christopher (UK)
Cc: Teco Boot; manet
Subject: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Ian

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 31 Oct 2007 16:06:34 +0100

> reference PacketBB, like TimeTLV.
Anyway, we have to update the packetbb document for it. Right now, it is
tailored for UDP and not for IP.
Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 15:35:37 -0000

> tailored for UDP and not for IP.

Actually, no it isn't. The letters "UDP" do not appear anywhere
in it. They used to (but only as an example), now they don't
appear at all. This was for this very reason.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 31 Oct 2007 18:59:41 +0100

> appear at all. This was for this very reason.

Partly agreed: UDP is not mentioned in packetbb.
Partly not agreed: OLSR, NHDP and DYMO mentions UDP.

My main concern is that if someone wants to use the manet IP_PROTO and
packetbb, something is missing. I don't like a transport protocol that does
not implement some kind of error detection.
Ian's proposal that it can be added in a future extension is acceptable for
me. Can we add some words on this in packetbb? I prefer text specifying that
it is required that lower layers MUST fulfill needs for integrity in case
packetbb does not provide such.
Otherwise, I am against requesting IP_PROTO.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 31 Oct 2007 18:04:01 -0000

> Partly not agreed: OLSR, NHDP and DYMO mentions UDP.

The former two have not been updated to correspond to
the latest draft-iana yet, they pre-date it. The same
may well be true of DYMO, but I'll let someone else
answer that.

> me. Can we add some words on this in packetbb?

packetbb is not the place for this. draft-iana might be,
or some potential future document. packetbb has removed
all such considerations.

---

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 1 Nov 2007 07:47:31 +0530

I do not think any modification needs to be made to PacketBB regarding
this matter. In the future, we can specify additional
behavior/protocols if/when it is needed.

As Chris stated, transport and integrety are not handled in PacketBB.

I could see the possible insertion of some text in NHDP, DYMO, OLSRv2,
and potentially another draft specifying an integrity TLV.

Ian