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

["Syam Madanapalli" <[e-mail]>]

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 <[e-mail]> 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:[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]]
> 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
>
>

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