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

["Qiang Zhang" <[e-mail]>]

sure 32 mask will not completely stop the node sending any gratuitous or
proxy ARP if it elects to, but at least the 32 mask can minimize the impact.

I was thinking in a EthCS context instead of IPv4CS, I think it was made
clear earlier (or is it decided?) ARP SHOULD be shadowed within the MN as it
is not part of the IP layer. But after all it seems a fishy implementation
for ARP, are you planning to provide the IP-CS in a SHIM fashion?



On 5/10/07, Bernard Aboba <[e-mail]> wrote:
>
>  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.
>
>
>  ------------------------------
>  *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]<[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 < [e-mail]>
> Date: Apr 17, 2007 12:22 AM
> Subject: [16NG] 68-IETF minutes
> To: "[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