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 <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 <mailto: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