RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)

["John.zhao" <[e-mail]>]

Hi Samita

 

         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? 

 

         Best Rgds,

Thanks,

 

John.zhao

 

  _____  

发件人: Samita Chakrabarti [mailto:[e-mail]] 
发送时间: 2007年5月11日 5:02
收件人: Bernard Aboba; [e-mail]; [e-mail]
抄送: [e-mail]; 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:[e-mail]]
Sent: Thu 5/10/2007 2:50 AM
To: [e-mail]; Bernard Aboba
Cc: 'Samita Chakrabarti'; [e-mail]; 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:[e-mail]] 
发送时间: 2007年5月10日 9:00
收件人: Bernard Aboba
抄送: Samita Chakrabarti; [e-mail]; 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 <[e-mail]> 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:[e-mail]]
Sent: Wed 5/9/2007 9:00 AM
To: Bernard Aboba
Cc: Samita Chakrabarti; [e-mail]; 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 <[e-mail] > 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:[e-mail]
<mailto:[e-mail]> ]
Sent: Tue 5/8/2007 6:59 PM
To: Syam Madanapalli; [e-mail]
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 < <mailto:[e-mail]>  [e-mail]>
Date: Apr 17, 2007 12:22 AM
Subject: [16NG] 68-IETF minutes
To: "[e-mail]  <mailto:[e-mail]> " <[e-mail]>

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng

 


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng

 

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng