Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
"Daniel Park" <soohongp@gmail.com> Wed, 09 May 2007 14:47 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 1HlnRu-0003Bf-EH; Wed, 09 May 2007 10:47:26 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1HlnRt-0003Ba-KE
for 16ng-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 10:47:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnRt-0003BS-Ah
for 16ng@ietf.org; Wed, 09 May 2007 10:47:25 -0400
Received: from wr-out-0506.google.com ([64.233.184.234])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlnRs-0006HT-Se
for 16ng@ietf.org; Wed, 09 May 2007 10:47:25 -0400
Received: by wr-out-0506.google.com with SMTP id 71so223997wri
for <16ng@ietf.org>; Wed, 09 May 2007 07:47:24 -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=uM3t4ktdSqgCEBRQgzsWyfiVa0lbvYxCAsgMPk8ujXZdsDVY7kLkWIkBbiGg8IbGEcL3DE5Z+0RoI0ZhNl2uAlJMY7w2+daAmDh68LbtynbOaydIhYwt7tv148mYMpCDq6FT1yC9Wq7nfslYJywveOAWQlu4m2gESF4barXfVe0=
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=RwkzZO+1AbtXbS6odUCT9I5PNU5CEWBpWu1+GkQo/Oo3zG7CYYUYHg6Zln7IWYPbuxFtoMMamYDFdDFbtWB0xys8pRPmJ5tBsATCYenIIrCwz6wu2pW+6aGVdqrp3MJPwyeDDSHv55PYxL2XyLUGo+t8Sad1Re/wm2pli9uDBJA=
Received: by 10.114.204.13 with SMTP id b13mr199802wag.1178722044040;
Wed, 09 May 2007 07:47:24 -0700 (PDT)
Received: by 10.115.94.7 with HTTP; Wed, 9 May 2007 07:47:23 -0700 (PDT)
Message-ID: <f7c7d76e0705090747r24ba0696x6c445e6886dc58d4@mail.gmail.com>
Date: Wed, 9 May 2007 16:47:23 +0200
From: "Daniel Park" <soohongp@gmail.com>
To: "Bernard Aboba" <bernarda@windows.microsoft.com>
Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
In-Reply-To: <0C7B902B470A264FA64D66CBF76FB8210358C66A@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <D4AE20519DDD544A98B3AE9235C8A4C2A7B21A@moe.corp.azairenet.com>
<0C7B902B470A264FA64D66CBF76FB8210358C66A@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e
Cc: Samita Chakrabarti <Samita.Chakrabarti@azairenet.com>, 16ng@ietf.org,
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>
Errors-To: 16ng-bounces@ietf.org
Yes, that was a resolution from Bernard during the last meeting in my memory. -- Daniel Park 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 > > > > > > > -----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] 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