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