Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
"Syam Madanapalli" <smadanapalli@gmail.com> Mon, 14 May 2007 15:48 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HncmS-0002BM-Fj; Mon, 14 May 2007 11:48:12 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1HncmQ-0002BB-9m
for 16ng-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:48:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HncmQ-0002B0-01
for 16ng@ietf.org; Mon, 14 May 2007 11:48:10 -0400
Received: from nz-out-0506.google.com ([64.233.162.227])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HncmP-00045p-9q
for 16ng@ietf.org; Mon, 14 May 2007 11:48:09 -0400
Received: by nz-out-0506.google.com with SMTP id z6so2002478nzd
for <16ng@ietf.org>; Mon, 14 May 2007 08:48:08 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=ubythD+aAabCf/hC5De7K1D1xBeMamp461+6XrfVD4oPIJlVsv+AGZMJVSqLXoq9deofXhGlc9gs2/xLVTXqAVliK5nITGyjJTUWds7qj+JNF26E5YGDbLD+qCgBCQnZ0WAK3JbKHlWFhpLfwbW5/V5aIY6uCrUy4f7e9LJK6MQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=KRYYACbv1EinNLq8CZgxcvsOTly6GS6cIKQyG8AXFbBC0tGqtZTnr7gjY6LLTRW+hadthSjQAhOD1IrkSbHwgQnc2JTlvp6fIml2Zm2rIMBXb1SmLhT1TTwBd/Rfp7orDxHaq/5gNcCQtHdEmPfvOx0TatEXmkWesndIgc0PG1M=
Received: by 10.115.76.1 with SMTP id d1mr1054383wal.1179157687800;
Mon, 14 May 2007 08:48:07 -0700 (PDT)
Received: by 10.115.109.20 with HTTP; Mon, 14 May 2007 08:48:07 -0700 (PDT)
Message-ID: <10e14db20705140848w4518df31x5ce8a5737a3a8b33@mail.gmail.com>
Date: Mon, 14 May 2007 21:18:07 +0530
From: "Syam Madanapalli" <smadanapalli@gmail.com>
To: "Premec, Domagoj" <domagoj.premec@siemens.com>
Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6802061F67@zagh223a.ww300.siemens.net>
MIME-Version: 1.0
References: <D4AE20519DDD544A98B3AE9235C8A4C2A7B512@moe.corp.azairenet.com>
<10e14db20705112035t3c312badn3f0bba026f9626bc@mail.gmail.com>
<3C31CDD06342EA4A8137716247B1CD6802061F67@zagh223a.ww300.siemens.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc
Cc: 16ng@ietf.org, Samita Chakrabarti <Samita.Chakrabarti@azairenet.com>,
Bernard Aboba <bernarda@windows.microsoft.com>,
Dave Thaler <dthaler@windows.microsoft.com>
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1501948282=="
Errors-To: 16ng-bounces@ietf.org
Hi Domagoj, I do not think, it is defined anywhere. Nonetheless that's my understanding. Two different nodes using two different CS need to interwork at IP layer hence will be on two different subnets. - Syam On 5/14/07, Premec, Domagoj <domagoj.premec@siemens.com> wrote: > Hi Syam, > > > The mobiles that use different CSs, will be on different subnets. > If this is defined / required by some document, could you please provide a pointer? > > thanks > domagoj > > > > -----Original Message----- > > From: Syam Madanapalli [mailto:smadanapalli@gmail.com] > > Sent: 12. svibanj 2007 05:35 > > To: Samita Chakrabarti > > Cc: Dave Thaler; Bernard Aboba; 16ng@ietf.org > > Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] > > 68-IETF minutes) > > > > Hi Samita, > > > > The mobiles that use different CSs, will be on different subnets. > > I do not think this is an issue for ARP. > > > > Thanks, > > Syam > > > > On 5/12/07, Samita Chakrabarti > > <Samita.Chakrabarti@azairenet.com> wrote: > > > > > > > > > > > > > > > > > > Hi John, > > > > > > > > > > > > > > > > > > My two cents. > > > > > > Based on IPv4CS, only IP packet be transported over the > > > connection between BS and MS. And generally a ARP packet is not the > > > same type as IP packet . So without Ethernet CS support, I > > don't think > > > the ARP packet will be transferred to ASN-GW , even in a > > p2p link mode. > > > > > > So that is my question. If the ARP didn't be > > disabled in MS, > > > then how to response it in MS? > > > > > > [SC>] > > > > > > I am not sure I understand your question. Are you asking, if the > > > mobile has not disabled ARP and is able to > > > > > > receive ARP somehow then how would it respond over IPV4CS link? > > > > > > It actually does not make sense for mobile in IPv4CS link > > to send or > > > receive ARP. So, I was trying to suggest that > > > > > > the mobile does not send ARP over IPv4CS link. Since ASN-GW is the > > > only one it talks to, it will not receive any > > > > > > ARP msg via ASN-GW either. Now what if one mobile is in > > IPV4CS link > > > and other one in etherCS link ? > > > > > > That's when things get complicated for ASN-GW. RFC4840 has > > a caution > > > about using multiple links in one ASN network. > > > > > > > > > > > > -Samita > > > > > > > > > > > > I > > > > > > > > > > > > > > > Best Rgds, > > > > > > Thanks, > > > > > > > > > > > > John.zhao > > > > > > > > > ________________________________ > > > > > > > > > 发件人: Samita Chakrabarti > > > [mailto:Samita.Chakrabarti@AzaireNet.com] > > > 发送时间: 2007年5月11日 5:02 > > > 收件人: Bernard Aboba; john.zhao@huawei.com; qiangieee@gmail.com > > > 抄送: 16ng@ietf.org; Dave Thaler; Samita Chakrabarti > > > 主题: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] > > 68-IETF minutes) > > > > > > Hi Bernard, > > > > > > > > > > > > > > > Just because the node has a /32 netmask doesn't mean it won't send > > > ARPs; see RFC 4436. I don't understand how the ASN can respond to > > > ARPs, since it will never receive them where the IPv4 CS is > > negotiated. > > > > > > [SC>] Let's see if we all have the same scenario in mind. > > MN<->ASN-GW > > > is a point-to-point link over IPv4CS. But the IP layer is > > not aware of > > > this convergence layer and expects to resolve MAC address by > > > sending/receiving ARP packets > > > > > > to its neighbors who share the same subnet prefix (or other > > definition > > > of on-link). > > > > > > > > > > > > You said above that ASN-GW will never receive a ARP packet > > since IPv4 > > > CS is negotiated, if that is true then > > > > > > how does any MN in the ASN network would possibly receive > > any ARP packet? > > > > > > > > > > > > Today many IP layer implementations are aware of the type of > > > link-layer of the outgoing/receiving interface type > > > > > > and accordingly they can make decision to send ARP or not. > > > > > > > > > > > > Generating ARP response within the device just for Wimax > > network does > > > not sound like a generic solution to me. > > > > > > > > > > > > Following the current generic IP layer mechanism, we can either say > > > that IP layer expects to resolve MAC addresses > > > > > > or it does not. If we believe that resolving ARP is > > necessary since we > > > want to emulate Ethernet style over IPCS, then > > > > > > we should send/receive ARP message to/from ASN-GW somehow. > > Otherwise, > > > the IP layer does not generate or expect > > > > > > to receive ARP message on this 802.16 interface. It is true > > for host > > > and ASN-GW both, on the IPv4Cs links. > > > > > > > > > > > > To explain further, if a dual-mode handset moves from Wi-fi > > network to > > > a Wimax access network, it could receive > > > > > > a trigger from the layer 2 that it has now moved to Wimax > > network and > > > a > > > 802.16 interface is configured. In Wimax > > > > > > network, DHCP DISCOVER msg is sent directly to the ASN-GW and it > > > should get assigned an address from ASN-GW. > > > > > > So, at this point the mobile node has a point-to-point link to the > > > ASN-GW which is its default router. > > > > > > I'd actually prefer no ARPing in IPv4CS case, since it would add > > > nothing but delay. > > > > > > > > > > > > Thanks, > > > > > > -Samita > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: John.zhao [mailto:john.zhao@huawei.com] > > > Sent: Thu 5/10/2007 2:50 AM > > > To: qiangieee@gmail.com; Bernard Aboba > > > Cc: 'Samita Chakrabarti'; 16ng@ietf.org; Dave Thaler > > > Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF > > > minutes) > > > > > > > > > Hi,folks > > > > > > > > > > > > May I ask a question. If the mac layer of MN > > response to the > > > ARP request, then what will be returned? Seems a non-specific MAC > > > address can be returned, right? > > > > > > > > > > > > Best Rgds, > > > > > > Thanks, > > > > > > > > > > > > John.zhao > > > > > > > > > ________________________________ > > > > > > > > > 发件人: Qiang Zhang [mailto:qiangieee@gmail.com] > > > 发送时间: 2007年5月10日 9:00 > > > 收件人: Bernard Aboba > > > 抄送: Samita Chakrabarti; 16ng@ietf.org; Dave Thaler > > > 主题: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] > > 68-IETF minutes) > > > > > > > > > > > > just want to throw in a thought, in the case of a node A trying to > > > ping its neighbor, on ethernet that are segmented as > > subnets, the node > > > A will trigger ARP REQ, I see two possible ways to work > > around it in > > > wimax > > > > > > 1. during the DHCP address assignment, the terminal's IP > > should be set > > > with netmask 32 therefore the node is on its own and won't do ARP, > > > lower layer emulation can try to take care of the > > addressing that is > > > needed for real routing to fill in the ether header with > > the ASN's MAC > > > address. This appears more a hack and don't need a standard > > > > > > from standard point of view, the below should be supported > > > > > > 2. ASN will need to respond to various ARP's from the nodes, for a > > > ARP_REQ, a. ASN can choose to respond with ARP_REP with its own MAC > > > address or MAC for the destination's real MAC if desired > > (if the ASN > > > prefers to be a bridge), b. ASN can choose to relay those > > ARP to those > > > logically correct subnets, this needs a help of a broadcast bridge > > > daemon; but regardless this does not seem to be really feasible > > > particularly when the nodes on logical subnet are spread > > over multiple > > > ASNs and roaming... > > > > > > So, for an implementaion either 1 or 2.a will work, there > > maybe other > > > methods too, Not sure if standard really needs to > > standardize on this > > > > > > > > > On 5/9/07, Bernard Aboba <bernarda@windows.microsoft.com> wrote: > > > > > > > > > > > > Yes, producing ARP response within the device. > > > > > > > > > > > > > > > > > > If the device is made to look like Ethernet (as many WiMAX NICs are > > > doing), then ARP requests will be received, so it is not > > possible to > > > avoid receiving ARPs. > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Syam Madanapalli [mailto:smadanapalli@gmail.com] > > > Sent: Wed 5/9/2007 9:00 AM > > > To: Bernard Aboba > > > Cc: Samita Chakrabarti; 16ng@ietf.org; Dave Thaler > > > Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF > > > minutes) > > > > > > > > > > > > Did you mean producing ARP response within the device? > > > > > > > > > Which I think is fine, but the best is not to send ARP at all. > > > > > > > > > > > > Thanks, > > > > > > > > > Syam > > > > > > > > > > > > > > > > > > On 5/9/07, Bernard Aboba <bernarda@windows.microsoft.com > wrote: > > > > > > > > > I think that the issue is resolved by enabling a unicast > > ARP response > > > to be synthesized in response to a unicast ARP request > > (e.g. NUD). Of > > > course, it is also necessary to respond to broadcast ARPs as well. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Samita Chakrabarti [ > > > mailto:Samita.Chakrabarti@AzaireNet.com] > > > Sent: Tue 5/8/2007 6:59 PM > > > To: Syam Madanapalli; 16ng@ietf.org > > > Cc: Bernard Aboba; Dave Thaler > > > Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF > > > minutes) > > > > > > Hi , > > > > > > > > > > > > I also am not clear on the issues with ARP comments in IPv4CS > > > document as Syam mentioned below. > > > > > > > > > > > > Can someone please clarify ? Please see in-line. > > > > > > > > > > > > >From 16ng minutes: > > > > > > .... > > > > > > Bernard Aboba: if Ethernet exposes an Ethernet interface then DNA > > > triggered. > > > then DHCP, so ARP is sent, then you figure out what to do Bernard > > > Aboba: problem dropping ARPs - you wont get an address if you do > > > > > > that, because in DNA you don't dhcp. no connectivity if > > dropping the > > > arp. > > > In any operating system you'll have no address > > > > > > [SC>] > > > > > > Is the concern with DNAv4 running on a mobile node ? I > > assume the node > > > tries to do autoconf with IPv4 link-local address by sending a > > > unicast packet to the default router and for that it needs > > to ARP for > > > the MAC address of the router? > > > > > > Is the concern on dropping ARP on the receiver side or not > > being able > > > to send an ARP at all or both? > > > > > > > > > Dave Thaler: respond to any MAC address, sounds as if what you're > > > proposing, manufcature ARP response... ARP goes on wire > > Bernard Aboba: > > > not get DHCP but get (MAC) address > > > > > > [SC>] > > > > > > Can DNA of a mobile get a hint from the link layer that it > > is now in > > > Wimax (802.16e ) link and then it should try to get its address > > > assigned according to the Wimax network (DHCP)? (Assuming > > the node has > > > moved from Wifi to Wimax network, for example). The DHCP > > address is > > > assigned usually by the ASN network. So if the concern is > > in initial > > > IP-address allocation, that might be handled by Wimax > > network. But, > > > if there is no address resolution, then how does a node > > send a packet > > > to its logical neighboring node ? It looks like the ASN-GW or > > > default-router in the network or some central body needs to do the > > > mapping between an IP-address to CID of the destination > > node. Thus > > > ARP request could be directly sent to the default GW which > > will act as > > > a proxy and send back a reply with a CID of the corresponding > > > IP-address(assuming the default gw has a cache of all nodes > > attached > > > to it). The model is similar to what is described in: > > > > > > > > http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd- > > > 03 > > > .txt > > > > > > > > > > > > Comments? > > > > > > > > > > > > Thanks, > > > > > > -Samita > > > .... > > > > > > > > > These minutes are recorded for the presentation of the ID > > > > > > draft-madanapalli-16ng-over-802-dot-16-ipcs-00 > > > > > > > > > > > > I did not understand these comments, especially Ethernet in > > the IPv4CS > > > context, > > > > > > Sorry I was not present at the meeting. > > > > > > > > > > > > The proposal is: > > > > > > As IP is run directly over 802.16 in case of IPv4 and > > destination MAC > > > address is > > > > > > not required for sending the frames, there is no need for ARP. > > > > > > Also, ARP frame does not has a IP header, so IPv4CS cannot > > map these > > > onto > > > > > > any CID. > > > > > > > > > > > > Or did I miss something? > > > > > > > > > > > > Thank you, > > > > > > Syam > > > > > > > > > ---------- Forwarded message ---------- > > > From: Daniel Park < soohongp@gmail.com> > > > Date: Apr 17, 2007 12:22 AM > > > Subject: [16NG] 68-IETF minutes > > > To: "16ng@ietf.org " <16ng@ietf.org> > > > > > > Can be found at: > > > http://www3.ietf.org/proceedings/07mar/minutes/16ng.txt > > > > > > Let me know if you see any bugs in there. > > > > > > -- Daniel Park > > > > > > > > > _______________________________________________ > > > 16NG mailing list > > > 16NG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > > > > > > > > > _______________________________________________ > > > 16NG mailing list > > > 16NG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > > > _______________________________________________ > > > 16NG mailing list > > > 16NG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > > >
_______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-I… Syam Madanapalli
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Samita Chakrabarti
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Bernard Aboba
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Daniel Park
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Syam Madanapalli
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Bernard Aboba
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Qiang Zhang
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … John.zhao
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Bernard Aboba
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Qiang Zhang
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Samita Chakrabarti
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … John.zhao
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Samita Chakrabarti
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Syam Madanapalli
- RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Premec, Domagoj
- Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] … Syam Madanapalli