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

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 8 May 2007 18:59:33 -0700

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 <[email-masked]>
Date: Apr 17, 2007 12:22 AM 
Subject: [16NG] 68-IETF minutes
To: "[email-masked]" <[email-masked]>

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 May 2007 19:53:38 -0700

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:[email-masked]]
Sent: Tue 5/8/2007 6:59 PM
To: Syam Madanapalli; [email-masked]
Cc: Bernard Aboba; Dave Thaler
Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
 
Hi ,

....

[SC>] 

[SC>] 

Comments?

Thanks,

-Samita
....

The proposal is:

any CID.

Or did I miss something?

Thank you,

Syam

---------- Forwarded message ----------
From: Daniel Park <[email-masked]>
Date: Apr 17, 2007 12:22 AM 
Subject: [16NG] 68-IETF minutes
To: "[email-masked]" <[email-masked]>

Can be found at:

-- Daniel Park

---

From: "Daniel Park" <[email-masked]>
Date: Wed, 9 May 2007 16:47:23 +0200

Yes, that was a resolution from Bernard during the last meeting in my memory.

-- Daniel Park

On 5/9/07, Bernard Aboba <[email-masked]> 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.
>
>
>
> From: Samita Chakrabarti
> [mailto:[email-masked]]
> From: Samita Chakrabarti
> [mailto:[email-masked]]

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 9 May 2007 21:30:31 +0530

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 <[email-masked]> 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.
>
>
> From: Samita Chakrabarti [mailto:[email-masked]<[email-masked]>
> ]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 May 2007 10:23:41 -0700

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:[email-masked]]
Sent: Wed 5/9/2007 9:00 AM
To: Bernard Aboba
Cc: Samita Chakrabarti; [email-masked]; Dave Thaler
Subject: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)

Thanks,
Syam

	
	-----Original Message-----
	From: Samita Chakrabarti [ mailto:[email-masked] <mailto:[email-masked]> ]
	Sent: Tue 5/8/2007 6:59 PM
	To: Syam Madanapalli; [email-masked]
	Cc: Bernard Aboba; Dave Thaler
	Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)
	
	Hi ,

	

	From 16ng minutes:
	
	....

	
	[SC>]

	
	[SC>]
	
	Wimax (802.16e ) link and then it should try to get its address assigned

	
	Comments?

	Thanks,
	
	-Samita
	....

	

	
	The proposal is: 

	
	
	any CID.

	Or did I miss something?

	Thank you,
	
	Syam

	---------- Forwarded message ----------
	From: Daniel Park < [email-masked] <mailto:[email-masked]> >
	Date: Apr 17, 2007 12:22 AM
	Subject: [16NG] 68-IETF minutes
	To: "[email-masked] " <[email-masked]>
	
	Can be found at:

	-- Daniel Park

---

From: "Qiang Zhang" <[email-masked]>
Date: Wed, 9 May 2007 21:00:27 -0400

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 <[email-masked]> wrote:
> 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:[email-masked]]
> *Sent:* Wed 5/9/2007 9:00 AM
> *To:* Bernard Aboba
> *Cc:* Samita Chakrabarti; [email-masked]; Dave Thaler
> *Subject:* Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF
> minutes)
>
> >  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
> > From: Samita Chakrabarti [ mailto:[email-masked]<[email-masked]>
> > ]
> > From: Daniel Park < [email-masked]>

---

From: "John.zhao" <[email-masked]>
Date: Thu, 10 May 2007 17:50:06 +0800

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:[email-masked]] 
发送时间: 2007年5月10日 9:00
收件人: Bernard Aboba
抄送: Samita Chakrabarti; [email-masked]; Dave Thaler
主题: Re: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)

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. 

  _____  

Thanks,

Syam

On 5/9/07, Bernard Aboba <[email-masked] > wrote: 

-----Original Message-----
From: Samita Chakrabarti [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tue 5/8/2007 6:59 PM
To: Syam Madanapalli; [email-masked]
Cc: Bernard Aboba; Dave Thaler
Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)

Hi ,

....

[SC>]

[SC>]

Comments?

Thanks,

-Samita
....

The proposal is: 

any CID.

Or did I miss something?

Thank you,

Syam

---------- Forwarded message ----------
From: Daniel Park < <mailto:[email-masked]>  [email-masked]>
Date: Apr 17, 2007 12:22 AM
Subject: [16NG] 68-IETF minutes
To: "[email-masked]  <mailto:[email-masked]> " <[email-masked]>

Can be found at:

-- Daniel Park

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 May 2007 08:45:18 -0700

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:[email-masked]]
Sent: Thu 5/10/2007 2:50 AM
To: [email-masked]; Bernard Aboba
Cc: 'Samita Chakrabarti'; [email-masked]; 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:[email-masked]] 
????: 2007?5?10? 9:00
???: Bernard Aboba
??: Samita Chakrabarti; [email-masked]; 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 

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

Thanks,

Syam

-----Original Message-----
From: Samita Chakrabarti [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tue 5/8/2007 6:59 PM
To: Syam Madanapalli; [email-masked]
Cc: Bernard Aboba; Dave Thaler
Subject: RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF minutes)

Hi ,

....

[SC>]

[SC>]

Comments?

Thanks,

-Samita
....

The proposal is: 

any CID.

Or did I miss something?

Thank you,

Syam

---------- Forwarded message ----------
From: Daniel Park < [email-masked] <mailto:[email-masked]> >
Date: Apr 17, 2007 12:22 AM
Subject: [16NG] 68-IETF minutes
To: "[email-masked] " <[email-masked]>

Can be found at:

-- Daniel Park

---

From: "Qiang Zhang" <[email-masked]>
Date: Thu, 10 May 2007 16:33:08 -0400

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 <[email-masked]> 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:[email-masked]]
> *Sent:* Thu 5/10/2007 2:50 AM
> *To:* [email-masked]; Bernard Aboba
> *Cc:* 'Samita Chakrabarti'; [email-masked]; Dave Thaler
> *Subject:* RE: [16NG] ARP over IEEE 802.16 IPvCS (was 16NG] 68-IETF
> minutes)
>
>  Hi,folks
>
>
>
> *发件人:* Qiang Zhang [mailto:[email-masked]]
> *发送时间:* 2007年5月10日 9:00
> *收件人:* Bernard Aboba
> *抄送:* Samita Chakrabarti; [email-masked]; 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
>
> On 5/9/07, *Bernard Aboba* <[email-masked]> wrote:
>
> On 5/9/07, *Bernard Aboba* <[email-masked] > wrote:
>