Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-02.txt & WGLC

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 11 May 2007 09:02:57 +0530

I'd like to ask people to review this new revision. I'm also reissuing WGLC.

Here is a summary of the main changes:

The draft has been revised to state clearly that a well-known UDP
port, LL multicast addresses, and SL multicast addresses are required
by the MANET WG.

I tried to remove any text specifying operational requirements/advice
related to these well-known values, as this type of discussion belongs
in the protocol specifications.

I choose to leave the site-local multicast addresses. This topic has
been discussed several times on the list and I believe there is
consensus that we should allocate these (IPv4/IPv6) addresses.

Please sent any questions/comments to the list.
Ian Chakeres

On 5/10/07, [email-masked] <[email-masked]> wrote:
> 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           : MANET IANA Needs
>         Author(s)       : I. Chakeres
>         Filename        : draft-ietf-manet-iana-02.txt
>         Pages           : 7
>         Date            : 2007-5-10
>
> This document enumerates IANA assignments for use by MANET WG
>    protocols.  Specifically, a UDP port, two link-local multicast group
>    addresses (IPv4 & IPv6), and two site-local multicast group addresses
>    (IPv4 & IPv6).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-02.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-02.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-02.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
>
>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 May 2007 12:29:38 +0200

Ian Chakeres wrote:
>  related to these well-known values, as this type of discussion
> belongs in the protocol specifications.
> 

What exactly is the need of a MANET protocol for a _site-local_ IPv6
multicast address?  How is that need different from existing routing
protocols (I'm asking because no existing routing protocol uses a 
_site-local_ IPv6 multicast address).

Why can't a MANET routing protocol use an IPv6 multicast address with a 
scope non-permanently assigned (like ff15) or with Internet scope (like 
ff0e).

In my oppinion a MANET routing protocol has no special needs for
_site-local_ multicast addresses (although it may need IPv6 multicast
addresses with larger than link).  Because the definition of a 'site' is
very vague in the static (non-MANET) world and has no meaning in a MANET
environment.

Alex

> 
> Please sent any questions/comments to the list. Ian Chakeres
> 
>> directories. This draft is a work item of the Mobile Ad-hoc
>> Networks Working Group of the IETF.
>> 
>> Title           : MANET IANA Needs Author(s)       : I. Chakeres 
>> Filename        : draft-ietf-manet-iana-02.txt Pages           : 7 
>> Date            : 2007-5-10
>> 
>> protocols.  Specifically, a UDP port, two link-local multicast
>> group addresses (IPv4 & IPv6), and two site-local multicast group
>> addresses (IPv4 & IPv6).
>> 
>> 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.
>> 
>> logging in, type "cd internet-drafts" and then "get
>> draft-ietf-manet-iana-02.txt".
>> 
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> Send a message to: [email-masked]. In the body type: "FILE
>> /internet-drafts/draft-ietf-manet-iana-02.txt".
>> 
>> command.  To decode the response(s), you will need "munpack" or a
>> MIME-compliant mail reader.  Different MIME-compliant mail readers 
>> "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.
>> 
>> _______________________________________________ manet mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>> 
>> 
> 
> 
> _______________________________________________ manet mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 11 May 2007 16:40:25 +0530

There is agreement that we need a well-known multicast address with a
scope larger than link.

I believe that site scoping is the closest match with the expressed need.

Using a non scoped address could cause leakage of manet routing
packets into the greater Internet.

I would not mind switching the text from site-scope to variable scope
(assignment at all scopes). Do you think this would be better fit?

There are a large list of protocols & assignments for variable
scoping. http://www.iana.org/assignments/ipv6-multicast-addresses

This scoping assignment includes "DVMRP on MOSPF", a multicast routing protocol.

Ian Chakeres

---

From: Brian Haberman <[email-masked]>
Date: Fri, 11 May 2007 08:51:26 -0400

First off, I have to echo Alex's concern.  Can someone enumerate what
the need is for the "greater than link-local" multicast address?

Secondly, referencing the DVMRP-over-MOSPF variable scope multicast
address doesn't make much sense.  That functionality was added to the
default list of reserved multicast addresses "just in case".  As far as
I know no one who still uses DVMRP over MOSPF.

Regards,
Brian

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 12 May 2007 12:42:56 +0530

I (and a bunch of other people) have expressed that there is a clear
desire to have a site scoped (larger than link actually) multicast
address for MANET routers. The purpose of this address would be to
allow greater than link scoped packets between MANET routers.

I cannot enumerate everyone's thoughts, but the use-cases are be wide
and varied. It could be used for MANET router discovery, MANET Border
Router communication/coordination, Autoconf assistance protocols,
dissemination of multicast group information to assist
SMF/multicast/nhdp, plus lots of other potential uses. Another use
case could be to assist in securing certain messages (that don't
require hop-by-hop modification) in an end-to-end fashion over
multiple hops.

Perhaps, it will not be used - but I think it is better to reserve it
now - than to wait and see.

Ian Chakeres

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sat, 12 May 2007 04:39:34 -0400

> require hop-by-hop modification) in an end-to-end fashion over

Are any of these use cases expressed in RFCs or I-Ds (and, if so, which ones) ?

Regards
Marshall

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 12 May 2007 17:51:57 +0200

Ian Chakeres wrote:
> address for MANET routers.

A 'site' scope is not the only scope larger than link.

>  and varied. It could be used for MANET router discovery,

I think we should be careful with terminology.  I think MANET router
discovery should include first and foremost ND router discovery (and 
that is link-local).

Which MANET protocol _discovers_ other routers (not on same link)?  I
thought they're hardcoded in config files.

> MANET Border Router communication/coordination, Autoconf assistance 
> protocols, dissemination of multicast group information to assist 
> SMF/multicast/nhdp, plus lots of other potential uses.

I think these are words that sound good, with potentially very
stimulating intelligent ideas; but I am afraid (afraid to say something
wrong), that there are no specs for these behaviours.

> Another use case could be to assist in securing certain messages 
> (that don't require hop-by-hop modification) in an end-to-end fashion
>  over multiple hops.

Ian, this surely goes into IRTF discussion.  Securing multicast
communication - and mobility or manet - is cleary something not agreed
to work on currently as standards track.  There is a little activity at
IETF to secure group/multicast communication and that doesn't include
mobility.  There are however large activities in IRTF about securing
mobile multicast communications at least in mobopts RG and recently a
new list dealing with that.  In this context, I am wondering why do you
cite in the MANET Working Group "securing certain messages" together
with a "site-scoped multicast address".

>  now - than to wait and see.

A risk I'd like to mention - reserve now for we don't know what - and
when we know what we'll reserve another one.

Alex

>> First off, I have to echo Alex's concern.  Can someone enumerate 
>> what the need is for the "greater than link-local" multicast 
>> address?
>> 
>>  address doesn't make much sense.  That functionality was added to
>>  the default list of reserved multicast addresses "just in case".
>> As far as I know no one who still uses DVMRP over MOSPF.
>> 
>> Regards, Brian
>> 
>> Ian Chakeres wrote:
>>> There is agreement that we need a well-known multicast address 
>>> with a scope larger than link.
>>> 
>>> I believe that site scoping is the closest match with the 
>>> expressed
>> need.
>>> 
>>> I would not mind switching the text from site-scope to variable 
>>> scope (assignment at all scopes). Do you think this would be 
>>> better fit?
>>> 
>>>>> The draft has been revised to state clearly that a well-known
>>>>>  UDP port, LL multicast addresses, and SL multicast addresses
>>>>>  are
>> required
>>>>> by the MANET WG.
>>>>> 
>>>>> related to these well-known values, as this type of 
>>>>> discussion belongs in the protocol specifications.
>>>>> 
>>>>> I choose to leave the site-local multicast addresses. This 
>>>>> topic has been discussed several times on the list and I 
>>>>> believe there is consensus that we should allocate these 
>>>>> (IPv4/IPv6) addresses.
>>>> 
>>>> What exactly is the need of a MANET protocol for a _site-local_
>>>>  IPv6 multicast address?  How is that need different from 
>>>> existing routing protocols (I'm asking because no existing 
>>>> routing protocol uses a _site-local_ IPv6 multicast address).
>>>> 
>>>> Why can't a MANET routing protocol use an IPv6 multicast 
>>>> address
>> with a
>>>> scope non-permanently assigned (like ff15) or with Internet 
>>>> scope
>> (like
>>>> ff0e).
>>>> 
>>>> In my oppinion a MANET routing protocol has no special needs 
>>>> for _site-local_ multicast addresses (although it may need IPv6
>>>>  multicast addresses with larger than link).  Because the 
>>>> definition of a
>> 'site' is
>>>> very vague in the static (non-MANET) world and has no meaning 
>>>> in a
>> MANET
>>>> environment.
>>>> 
>>>> Alex
>>>> 
>>>>> 
>>>>>> 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           : MANET IANA Needs Author(s)       : I. 
>>>>>> Chakeres Filename        : draft-ietf-manet-iana-02.txt 
>>>>>> Pages           : 7 Date            : 2007-5-10
>>>>>> 
>>>>>> This document enumerates IANA assignments for use by MANET
>>>>>>  WG protocols.  Specifically, a UDP port, two link-local 
>>>>>> multicast group addresses (IPv4 & IPv6), and two site-local
>>>>>>  multicast group addresses (IPv4 & IPv6).
>>>>>> 
>>>>>> 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-02.txt".
>>>>>> 
>>>>>> Send a message to: [email-masked]. In the body type: 
>>>>>> 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] 
>>>>> _______________________________________________ manet mailing
>>>>>  list [email-masked] 
>>> _______________________________________________ manet mailing 
>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>> 
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 12 May 2007 17:55:30 +0200

>  (assignment at all scopes). Do you think this would be better fit?

I think that could be a good idea, but without knowing which are the
uses of all these addresses it sounds like address waste.

I think another way would be to wait that the need for this address is
more clear.

Yet another way is to request definition of a new scope.

If I were to choose right now between all these possible ways forward
I'd say to wait that the need is clear.

> This scoping assignment includes "DVMRP on MOSPF", a multicast

I don't think we have any common idea about a MANET multicast routing
protocol right now, such as to require a multicast address for it.  Or I
don't.

Alex

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 May 2007 10:58:23 -0400

I would argue that reserving a multicast address "just in case" is a bad
idea.  These potential functions, when defined in an I-D, can make the
IANA request themselves based on their stated needs.

Regards,
Brian

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 17 May 2007 08:43:49 +0200

Just for the record, I voice my support for the IANA document as-is,  
and I believe that it should go forward.

I see the allocations for ports and addresses (scopes) as appropriate  
for what we need currently in the routing protocols, as well as the  
design of the SMF framework.

Thomas

On May 11, 2007, at 5:32 AM, Ian Chakeres wrote:

>> group

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/