Re: [manet] MANET Terminology Update
Joe Macker <jpmacker@gmail.com> Mon, 23 July 2012 15:37 UTC
Return-Path: <jpmacker@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256C11E807F for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wILKQ3A6Vwux for <manet@ietfa.amsl.com>; Mon, 23 Jul 2012 08:37:04 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E872811E8096 for <manet@ietf.org>; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
Received: by yhq56 with SMTP id 56so6127415yhq.31 for <manet@ietf.org>; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=cs9jwicnShkMCQ8s1LJOdg6AKN29DGiGleShjgohJ20=; b=dfZskag9Ib5rJ5IZglYfXnW58pdYLiCevedA/gyR3r5lfcrkyzjvljnUepRvGFzxIo x++2aeIJ9GbaEX8KDNH7SDXQT64QAHbk8NV7ztmiQ3kOw5s2N4/bLkV4NJ5s0aCJCoY/ OxJDobmEbv40UStmvnq6IUdLbM+Om+iauzvE0vXPnpW6abNZP86tKJ4fMpX2pkhWXeG8 oQk0rZ/uouuGESjKrtrfQFOUJauMGEhY9cTIy3izsh91kytQSWu0MB19AhS5qMn2Op57 M4ahbRh5AwKdsAv8lQXyQ6uHXCl5UiCnlRr4CdGSPzTx9saA5roRlgq3/fAuh+shtVEL +sXw==
Received: by 10.236.161.72 with SMTP id v48mr14895514yhk.84.1343057823449; Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
Received: from ?IPv6:2002:458c:9704:1234:3cc8:3c42:cdb1:edb9? ([2002:458c:9704:1234:3cc8:3c42:cdb1:edb9]) by mx.google.com with ESMTPS id q3sm12680492ani.15.2012.07.23.08.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 08:37:03 -0700 (PDT)
References: <CADnDZ89NQS+tFVDsBjb_TZ2B-jL-o95Gx2HA5AbpRf2a8CstSg@mail.gmail.com> <B4130C17-45C2-485D-B2E4-3B9E16CA85DD@gmail.com> <CADnDZ88AQf_GLxjqdbB47EsACg+gnxHX9YJW5PZpOJzC32bR+A@mail.gmail.com> <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> <CADnDZ888Sh_edm4XmPvvzrgN8WAK+NAWMCZEh7PuG-wJYLbMeQ@mail.gmail.com> <8A25B620-D502-4C37-B292-B185331B1669@cisco.com>
In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <30FD7097-ED54-4D5C-A1A2-7D45F62AFDB0@gmail.com>
X-Mailer: iPhone Mail (9B206)
From: Joe Macker <jpmacker@gmail.com>
Date: Mon, 23 Jul 2012 11:40:06 -0400
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
Cc: manet <manet@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>, Abdussalam Baryun <abdussalambaryun@gmail.com>
Subject: Re: [manet] MANET Terminology Update
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jul 2012 15:37:06 -0000
Additional +1 I believe there is no need for this Sent from my iPhone On Jul 23, 2012, at 10:59 AM, "Stan Ratliff (sratliff)" <sratliff@cisco.com> wrote: > I'm going to "+1" one (and only one) sentence in this email thread: > >> >> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote: >>> I do not see the need for this terminology document in MANET: >> > > In my opinion as a working group participant, this is an unnecessary distraction for the working group, and will not result in a meaningful document. I will not support it. > > Regards, > Stan > > > > > On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote: > >> Hi >> >> Comment inline below: >> >> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote: >>> I do not see the need for this terminology document in MANET: >>> >>> o The RFCs published by the WG all do a good job of defining their proper >>> terminology and conventions in the sections, aptly named to this >>> effect -- and something which both the WG and the IESG has been very >>> vigilant in ensuring. >> >> Agree >> >>> >>> o Extracting this terminology, to present without the context of the RFC in >>> >>> which they are introduced and used, is both futile and a source >>> of errors and confusion. >> >> It is not extracting any thing it is locating information in easy >> location to be reached efficiently by researchers, or other WG >> participants. In another reason, for example the RFC5444 and RFC6130 >> is providing a MANET standard, while any RFC in this WG is specifying >> its own terminology and message format, but the reason was to bring >> RFCs to have similar formating functions. The terminology RFCs in many >> WGs does the same. RFC2501 is doing a good job to bring understanding >> of MANET which the terminology informational RFCs are doing in each >> concept/group-charter. >> >>> >>> o The domain evolves, new protocols appear and introduce new concepts, >>> terms. This is captured by carefully defining such in the RFC specifying >>> that protocol. Any terminology document (aside from all its other issues, >>> indicated in this list) would likely be obsolete and incomplete before >>> the >>> ink with which it was written was dry. >> >> So when new concepts appear any WG needs to prepare updates I-D to >> their information/standards/experiments so that knowledge is >> consistent and concepts are updated as will (including terminology >> document can be updated). Please note that our documents in MANET are >> a source of information to any participant in IETF, so we need to >> focus to not only produce new concepts/work but we see into >> update/obsolete previous work if possible/necessary. other wise why >> did the IETF make an option possibility to *update* and *obsolete* if >> they are not needed for WGs. >> >>> >>> o All RFCs in MANET uses no more than a small subset of the total MANET >>> (and Internet) terminology. A collective terminology document would, >>> therefore, necessarily be adding entropy to any single RFC and to the >>> WG (and to implementers of the WG protocols). >> >> Please note that the bigest reason of terminology is that when WG >> participants discuss things they don't misunderstand. Please note >> there are many times in MANET WG there are misunderstood in technical >> terms (I have references on the list to many incidence if you ask), so >> if experts have this problem we need to solve it by a RFC document, >> also we need to give the protocol user a sense of the general/specific >> terminology (as we have MANET general format, MANET general >> understanding, MANET general direction). >> >>> >>> o Certainly, a large number of terms in this document are entirely out of >>> scope >>> (such as those pertaining to non-MANET developed concepts or protocols, >>> e.g., those developed in other parts of the IETF), are useless for the WG >>> (such as, but not exclusively, "communication channel" and "communication >>> >>> medium"), are by nature ambiguous (such as, but not exclusively, "Upper >>> Layer" >>> and "Node"), carry a legacy that renders them difficult to use (such as, >>> but >>> not exclusively, "Logical (virtual) Link", "Physical Link", and "Link"). >>> >> >> I disagree that thoes terms are out of scope of the I-D of the MANETs >> context terminology, because those terms you mentioned were used in >> one/some MANET RFCs, so they need to be explained to bring all terms >> together to make overall knowledge to internet community. Your >> argument is right only if we are not specifying network-protocols, so >> because we are doing a type of network, then our documents for it >> SHOULD be *connected* by some combined meaning/knowledge *words*, so >> other (i.e. all internet community) can understand, without any >> possibility of misunderstanding (there are many examples I can give if >> you want). >> >> I thank you for your comments, and I will prepare a new version for the I-D, >> >> Best Regards >> >> Abdussalam Baryun >> ===================== >>>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>>>> >>>>>> Dear All >>>>>> >>>>>> I completed the first version of draft on terminology and submited the >>>>>> draft yesterday (with getting some techniq problem), but needed to >>>>>> post to know the community feedback and advise. There are other terms >>>>>> that was not yet included which will need some advise from you. >>>>>> Thanking you, >>>>>> >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> Abbreviations Used in The submitted Document >>>>>> >>>>>> AH Authentication Header >>>>>> DAD Duplicate Address Detection >>>>>> DPD Duplicate Packet Detection >>>>>> DoS Denial of Service >>>>>> ESP Encapsulating Security Payload >>>>>> IP IPv4 or IPv6 >>>>>> ICMP Internet Control Message Protocol >>>>>> IIB Interface Information Base >>>>>> ETX Estimated Expected number of Transmission >>>>>> FIB Forwarding Information Base >>>>>> LQI Link Quality Indicator >>>>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>>>> LLN Low power and Lossy Network >>>>>> MAC Mediam Access Control >>>>>> MIB Management Information Base >>>>>> MTU Maximum Transmission Unit >>>>>> NBMA Non-Broadcast Multi-Access link >>>>>> NHDP Neighborhood Discovery Protocol >>>>>> ND IP Neighbor Discovery >>>>>> OSPF Open Shortest Path First >>>>>> RIB Routing Information Base >>>>>> SMF Simplified Multicast Forwarding >>>>>> TCP Transmission Control Protocol >>>>>> UDP User Datagram Protocol >>>>>> >>>>>> 2.3 Definitions for MANET Terms >>>>>> >>>>>> 2.3.1 Terms Definition of MANET Communication: >>>>>> >>>>>> Communications’ Technology or Facility: >>>>>> The means employed by two or more devices/subsystems to transfer >>>>>> and/or receive information between them in one way or two way >>>>>> communication. MANET communications often uses the wireless >>>>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>>>> space, air, water, antenna, coaxial cables, etc.) >>>>>> >>>>>> Communication Medium: >>>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>>>> satellite system, etc.) that the routing device uses to communicates >>>>>> through the transmission medium(s), by providing connectionless and/or >>>>>> connection services that MAY be established. The system medium >>>>>> includes MAC layer and MAY include the physical Layer. >>>>>> >>>>>> Communication Channel: >>>>>> A subdivision of the physical communication medium (i.e. radio carrier >>>>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>>>> independent uses of the medium. Channels may be made available by >>>>>> subdividing the medium into; distinct time slots, distinct spectral >>>>>> bands, or coding sequence, etc. >>>>>> >>>>>> MANET Protocol: >>>>>> The communication system/subsystem that operates and maintains the >>>>>> ad hoc communication technology or facility within MANET. MANET routing >>>>>> Protocols often apply distributed algorithms/techniques to disseminate >>>>>> or forward routing messages within a MANET routing domain. >>>>>> >>>>>> Topology: >>>>>> An abstract representation of a network (physical or logical), as a >>>>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>>>> that >>>>>> communicate through set of links (E), where the G = (V, E). >>>>>> >>>>>> Physical-level Topology: >>>>>> A topology of the communication medium networks consists of routing >>>>>> devices and physical links. This topology information is updated by >>>>>> devices’ technology in the L2 information Base. >>>>>> >>>>>> Network-level Topology: >>>>>> A topology of the communication system networks consists of routers and >>>>>> links. This topology information is updated by routers in its RIB. >>>>>> >>>>>> Multihop MANET: >>>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach the >>>>>> destination. >>>>>> >>>>>> Reactive Routing: >>>>>> An on-demand based routing protocol that operates route discover and >>>>>> maintainance the route(s), to reach the demanded destination(s). >>>>>> >>>>>> Proactive Routing: >>>>>> A topology RIB based routing protocol that operates routes and >>>>>> maintains >>>>>> the network topology, to reach its known destination(s). Each router >>>>>> maintains routes to all reachable destinations at all times, whether or >>>>>> not there is currently any demand to deliver packets to those >>>>>> destinations. >>>>>> >>>>>> Upper Layer: >>>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>>>> >>>>>> MANET Domain: TBD >>>>>> >>>>>> MANET Signaling: >>>>>> Sending and exchanging some MANET messages/information. >>>>>> >>>>>> 2.3.2 Terms Definition of MANET Elements >>>>>> >>>>>> Node: >>>>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>>>> MANET signaling. It either runs a MANET routing protocol or participate >>>>>> in MANET signaling. >>>>>> >>>>>> Router: >>>>>> A MANET node that MUST implement a MANET routing protocol and forwards >>>>>> IP packets not explicitly addressed to itself. >>>>>> >>>>>> Host: >>>>>> A node that is not a router. All destinations in MANET that receive >>>>>> delivered data are hosts. >>>>>> >>>>>> Link: >>>>>> A link between two node interfaces. This link may be Logical >>>>>> (i.e. virtual) link or physical link. Logical links are between two >>>>>> logical interfaces and physical links are between two physical >>>>>> interfaces. Links are either unidirectional or bidirectional >>>>>> (links may be on-link and off-link: see RFC4861). >>>>>> >>>>>> >>>>>> Physical Link: >>>>>> a communication facility or medium over which the nodes can >>>>>> communicate at the link layer, i.e., the layer immediately below >>>>>> IP. Physical interfaces are the nodes’ attachment to physical links. >>>>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>>>> and shared-media, etc (see link types in ND [RFC4861]). >>>>>> >>>>>> Logical (virtual) Link: >>>>>> a communication facility (at L3, or upper-layer) over which nodes can >>>>>> communicate. This logical link is between two MANET interfaces exists >>>>>> if either can be heard by the other. >>>>>> >>>>>> Link MTU: >>>>>> the maximum transmission unit (i.e. maximum unit size in octets), that >>>>>> can be conveyed in one transmission unit over the link. >>>>>> >>>>>> >>>>>> Node Interface: >>>>>> A node's point of attachment to a link. Each node MUST have at least >>>>>> one >>>>>> interface that SHOULD be assigned an IP address. If there is/are more >>>>>> than one interface(s) per node then the additional interface(s) MAY be >>>>>> assigned an IP address. If an interface is not assigned to an IP >>>>>> address >>>>>> it MUST be identified by the MANET routing protocol. An interface MAY >>>>>> be >>>>>> assigned one or more addresses. >>>>>> >>>>>> MANET Interface: >>>>>> A node interface that participate in; exchange MANET information used >>>>>> in >>>>>> MANET routing or exchange information in MANET neighbor node discovery >>>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned >>>>>> to >>>>>> least one address to communicate. A router interface MUST be >>>>>> assigned a routable address which is the main address for the >>>>>> interface. >>>>>> >>>>>> >>>>>> 2.3.3 Terms Definition of MANET Identifications: >>>>>> >>>>>> An interface MAY be assigned one or more addresses. If the interface is >>>>>> a logical interface it MAY be assigned to only logical addresses, but >>>>>> if >>>>>> it is a physical interface MAY be assigned with physical address >>>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>>>> MANET addresses). >>>>>> >>>>>> >>>>>> MANET Address >>>>>> A MANET-subnet, node, or interface address. Node and interface >>>>>> addresses >>>>>> are either IP addresses or RFC5444 addresses. All subnet addresses are >>>>>> unicast IP addresses. >>>>>> >>>>>> Address Block and TLV: as specified in RFC5444 >>>>>> >>>>>> Routable address: >>>>>> A subnet address which can be a destination address. A router MUST be >>>>>> able to distinguish a routable address from a non-routable address. >>>>>> Broadcast, and multicast addresses, limited in scope to less than the >>>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>>>> addresses MAY be considered as routable addresses. >>>>>> >>>>>> Main address >>>>>> A routable address (MANET address) that is assigned to one router's >>>>>> MANET interface. >>>>>> >>>>>> Originator address: >>>>>> A node address of the node that originated a MANET message (this >>>>>> message >>>>>> MUST include the originator address). It MAY be a routable or an >>>>>> unroutable address. >>>>>> >>>>>> subnet prefix >>>>>> A bit string that consists of some number of initial bits of an IP >>>>>> address. >>>>>> >>>>>> Interface identifier >>>>>> the remaining low-order bits in the node's IP address after the subnet >>>>>> prefix. A number used to identify a node's interface on a link. >>>>>> >>>>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>>>> >>>>>> Packet: >>>>>> A MANET packet of a header plus payload. These packets are either >>>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>>>> in IP packet. Packets are generated by nodes to be sent to >>>>>> destination(s) through MANET or through the Internet. RFC5444 packets >>>>>> information MAY not be used only by MANET routers. >>>>>> >>>>>> Message: >>>>>> A MANET data message or routing control message. Routing control >>>>>> messages are either MANET routing protocol messages or/and RFC5444 >>>>>> messages. >>>>>> >>>>>> Type Length Value coding (TLV): >>>>>> A generic way to represent MANET information (as in [RFC5444] and >>>>>> [RFC5497]). >>>>>> >>>>>> Frame: >>>>>> A L2 protocol TLV with a header and payload. In some technologies the >>>>>> L2 >>>>>> operates a MANET routing protocol as a local area networking system. >>>>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>>>> telecommunication network. >>>>>> >>>>>> Route Request Message (RREQ) >>>>>> A message is used to discover a valid route to a particular >>>>>> destination address, called the RREQ Target Node. When a router >>>>>> processes a RREQ it learns routing information on how to Originator >>>>>> Node. >>>>>> >>>>>> Route Reply Message (RREP) >>>>>> A message is used to disseminate routing information about >>>>>> the RREP Target Node to the RREQ Originator Node and the intermediate >>>>>> routers. >>>>>> >>>>>> Route Error Message (RERR) >>>>>> A message is used to disseminate the information that a route is >>>>>> not available for one or more particular addresses. A RERR message is >>>>>> used to indicate that a router does not have a forwarding route >>>>>> to one or more particular addresses. >>>>>> >>>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>>>> >>>>>> Hop-by-hop Routing: (TBD) >>>>>> A dynamic routing that routes to destination by routing table. >>>>>> >>>>>> Source Routing: (TBD) >>>>>> A dynamic routing that its route path is provided in the IP packet. >>>>>> >>>>>> Route Discovery: TBD >>>>>> >>>>>> Route Maintenance: TBD >>>>>> >>>>>> Neighbor discovery: (TBD) >>>>>> A node discovers neighbors only if the node receives from it's >>>>>> neighbors. >>>>>> >>>>>> >>>>>> Multipoint relay (MPR): (TBD) >>>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>>>> its selection of router X1 as an MPR in a recent HELLO message. >>>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>>>> participate in the flooding process of messages received from >>>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>>>> declare link-state information for the link from X1 to Y1. It may >>>>>> also be both at the same time. >>>>>> >>>>>> MPR selector: >>>>>> A router, Y, is a flooding/routing MPR selector of router X if >>>>>> router Y has selected router X as a flooding/routing MPR. >>>>>> >>>>>> Router Parameters: >>>>>> boolean or numerical values, specified for each router, and not >>>>>> specific to an interface. A router MAY change router parameter >>>>>> values at any time, subject to some MANET constraints. >>>>>> >>>>>> MANET Routing Metric: >>>>>> A MANET routing cost that is governed by specific rules and properties >>>>>> defined by the MANET routing protocol which captures specific link or >>>>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>>>> LQI, >>>>>> etc. >>>>>> >>>>>> Distance Vector Metric >>>>>> A metric class related to rules of the MANET interface and MANET path >>>>>> distance. The metric can be calculated by the distance vector routing >>>>>> algorithm class used by the MANET routing protocol. A metric of the >>>>>> distance a message or piece of information has traversed. The minimum >>>>>> value of distance is the number of IP hops traversed. >>>>>> >>>>>> Link State Metric >>>>>> A metric type related to the MANET network-topology status and logical >>>>>> links' states. This metric is calculated by the link state routing >>>>>> algorithm class used by the MANET routing protocol. A metric type maybe >>>>>> EXT, LQL, etc. >>>>>> >>>>>> Link Metric: TBD >>>>>> >>>>>> Neighbor Metric: TBD >>>>>> >>>>>> Path accumulated: >>>>>> The RREQ message accumulates intermediate routers that are in path to >>>>>> destination(s). >>>>>> >>>>>> Protocol Sequence Number: >>>>>> A Sequence Number related to a MANET protocol that maintained by each >>>>>> protocol subsystem process. This sequence number is used by other >>>>>> subsystems to identify the temporal order of protocol information >>>>>> generated. >>>>>> >>>>>> Router Sequence Number: >>>>>> A router sequence number is maintained by each router process. The >>>>>> sequence number is used by other routers to identify the temporal >>>>>> order of routing information generated and ensure loop-free routes. >>>>>> >>>>>> MANET Information Base: >>>>>> A collection of information (in Table or Cache structure) maintained >>>>>> by MANET protocols and which is to be made available to MANET routing >>>>>> protocols. An Information Base may be associated with a MANET router >>>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB). >>>>>> >>>>>> RIB Entry: >>>>>> The RIB entry is a conceptual data structure. Implementations may use >>>>>> any internal representation that conforms to the semantics of a route >>>>>> as specified in the router specification. >>>>>> >>>>>> 3. IP Considerations and Terminology >>>>>> >>>>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>>>> run/implement at least one MANET routing protocol. The >>>>>> terminologies described in this document can be used for >>>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>>>> >>>>>> IP address: >>>>>> IPv4 addresses or IPv6 addresses. >>>>>> >>>>>> IP Packet: >>>>>> The packet header plus payload as specified in [RFC791] and [RFC2460] >>>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >>>>>> specified by RFC5498. >>>>>> >>>>>> Mobile IP considerations: >>>>>> Mobile IP terms are provided in [RFC6275], and this technology >>>>>> assists nodes while connected through the Internet domain(s). MANET >>>>>> is an infrastructure-less network that is able to communicate with >>>>>> the Internet (i.e. an IP infrastructure network). >>>>>> >>>>>> 4. Security Consideration and Terminology >>>>>> >>>>>> It is RECOMMENDED that MANET routing protocols consider security >>>>>> issues because the MANET's transmission medium is wireless which make >>>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>>>> routing information while traversing the MANET MAY be used by an >>>>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>>>> >>>>>> The following are some terminology related to MANET threats and >>>>>> security. >>>>>> >>>>>> Attacker: A node, present in the network and which intentionally seeks >>>>>> to compromise information based in MANET router(s). The Attacker MAY be >>>>>> a compromised MANET router if obtained MANET identity or routing >>>>>> information. >>>>>> >>>>>> Compromised MANET Router: An attacker router, present in MANET and >>>>>> which generates syntactically correct routing control messages. Control >>>>>> messages emitted by compromised router(s) may contain additional >>>>>> information, or omit information, as compared to a control message >>>>>> generated by a non-compromised router located in the same MANET >>>>>> topological position. >>>>>> >>>>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>>>> MANET Router. >>>>>> >>>>>> Jamming Attack: >>>>>> The attacker transmits massive amounts of interfering radio traffic, >>>>>> which will prevent legitimate traffic (e.g., routing and data traffic) >>>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>>>> influencing Legitimate MANET Router to transmit unnecessary >>>>>> information. >>>>>> >>>>>> Eavesdropping: >>>>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>>>> information or the transmitted data information from its neighbor's >>>>>> transmitted radio packet. Attacker’s processes MANY be used by attacker >>>>>> to mislead routing. Eavesdropping does not pose a direct threat to the >>>>>> MANET or to its routing. >>>>>> >>>>>> Identity Spoofing: >>>>>> Attacker sends routing messages, pretending to have the MANET identity >>>>>> of another node. >>>>>> >>>>>> Link Spoofing: >>>>>> Compromised MANET router sends routing messages to neighbor node(s) >>>>>> providing incorrect set of link information. >>>>>> >>>>>> Replay Attack: >>>>>> A Compromised router in one MANET region records control traffic >>>>>> information and replays the recorded information in a different MANET >>>>>> region (this type of attack is also called the Wormhole attack). >>>>>> >>>>>> Broadcast Storm: >>>>>> Compromised MANET router may attack the MANET by attempting to change >>>>>> the MANET flooding algorithm(s) to increase routing overheads or/and to >>>>>> increase the route discovery delay. Broadcast storm degrades the data >>>>>> traffic delivery and MANET performance. >>>>>> >>>>>> Falsification in MANET: >>>>>> The compromised MANET router sends false routing information into >>>>>> MANET. >>>>>> False routing information received in MANET, MAY create unrealistic >>>>>> information bases. >>>>>> >>>>>> ICMP Attacks: >>>>>> The generation of ICMPv6 error messages may be used by compromised >>>>>> MANET >>>>>> router to attempt DoS attacks by sending an error-causing source >>>>>> routing >>>>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>>>> the >>>>>> upper-layer processes, it is possible to perform attacks on the upper >>>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>>>> RECOMMENDED to perform some form of validation to ICMP messages (using >>>>>> the information contained in the payload of the ICMP message) before >>>>>> acting upon them. >>>>>> >>>>>> Source Routing Attacks: TBD >>>>>> >>>>>> Acknowledgments: >>>>>> >>>>>> This work has used/modified terms of the following documents: RFC2462, >>>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>>>> Gratefully acknowledge to the IETF community and all contributions. >>>>>> >>>>>> Reference: >>>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>>>> NHDP", Work in progress, March, 2012. >>>>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>>>> Networks", John Wiley & Sons, March 2007. >>>>>> ISBN: 978-0-471-75688-0. >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> >>>>>> I hope to get some advise from the Internet community to make the >>>>>> definitions more suitable/accurate, because I MAY misunderstood. >>>>>> Thanking you, >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> ===================== >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet
- Re: [manet] MANET Terminology Update Dearlove, Christopher (UK)
- [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Stan Ratliff
- Re: [manet] MANET Terminology Update Charles E. Perkins
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Stan Ratliff
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Teco Boot
- Re: [manet] MANET Terminology Update Ulrich Herberg
- Re: [manet] MANET Terminology Update Don Sturek
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] [Roll] MANET Terminology Update Jiazi YI
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Thomas Heide Clausen
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Abdussalam Baryun
- Re: [manet] MANET Terminology Update Stan Ratliff (sratliff)
- [manet] Fwd: MANET Terminology Update Stan Ratliff (sratliff)
- Re: [manet] MANET Terminology Update Joe Macker
- Re: [manet] MANET Terminology Update Don Sturek
- Re: [manet] MANET Terminology Update Ulrich Herberg
- Re: [manet] MANET Terminology Update Bo Berry