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

["Premec, Domagoj" <[e-mail]>]

Hi Syam,

> The mobiles that use different CSs, will be on different subnets. 
If this is defined / required by some document, could you please provide a pointer?

thanks
domagoj


> -----Original Message-----
> From: Syam Madanapalli [mailto:[e-mail]] 
> Sent: 12. svibanj 2007 05:35
> To: Samita Chakrabarti
> Cc: Dave Thaler; Bernard Aboba; [e-mail]
> Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 
> 68-IETF minutes)
> 
> 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