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

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

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