RE: [16NG] DAD in IEEE802.16

["Tjandra Paula-CPT015" <[e-mail]>]

Ok. I understand now.
But, the IP stack might not be aware of the CS type. For example, where the MS is a PCMCIA card and the IP stack actually is on the PC. In this case, there might still be ambiguity. I guess, in that case the IP stack could still perform DAD although it is connected to p2p link.
 
Thanks, Paula.

________________________________

From: Behcet Sarikaya [mailto:[e-mail]] 
Sent: Friday, May 04, 2007 2:22 PM
To: Tjandra Paula-CPT015
Cc: [e-mail]
Subject: Re: [16NG] DAD in IEEE802.16


Hi Paula,
  The confusion here is due to the fact that in 802.16 links both are possible: for Ethernet CS the shared link and for IPv6 CS p2p link models are used. Since MS will use either one of the CS's I think there is no ambiguity on the MS side.
  I don't think there is a RA option to indicate the link model used.
 
Regards,
 
Behcet


----- Original Message ----
From: Tjandra Paula-CPT015 <[e-mail]>
To: Behcet Sarikaya <[e-mail]>
Cc: [e-mail]
Sent: Friday, May 4, 2007 11:23:10 AM
Subject: RE: [16NG] DAD in IEEE802.16


Hi Behcet,
 
You said "if the two conditions .. are satisfied .."
 
If we allow 802.16 network to use either shared or point to point link model, how can an MS/host learn (as it enters an 802.16 network) whether the 802.16 network implements shared IPv6 prefix link model or point to point link model? 
 
I think in order for the MS/host to skip DAD in 802.16 network, the MS must be able to assume that all 802.16 networks satisfies the two conditions (like in 3GPP).
If some 802.16 networks are implementing shared prefix link model, then:
- MS must always perform DAD or
- the network somehow has to tell the MS/host whether it implements shared or point-to-point link model. Is there anything (router advertisement extension) defined for this purpose? 
 
Thanks, 
Paula.


________________________________

From: Behcet Sarikaya [mailto:[e-mail]] 
Sent: Thursday, May 03, 2007 5:57 PM
To: Tjandra Paula-CPT015
Cc: [e-mail]
Subject: Re: [16NG] DAD in IEEE802.16


This is covered in Sec. 9.2 of <draft-ietf-16ng-ipv6-over-ipv6cs>.
If the two conditions given there are satisfied then no DAD is needed.
 
--behcet

----- Original Message ----
From: Tjandra Paula-CPT015 <[e-mail]>
To: Behcet Sarikaya <[e-mail]>; gabriel montenegro <[e-mail]>
Cc: [e-mail]
Sent: Thursday, May 3, 2007 5:18:38 PM
Subject: RE: [16NG] DAD in IEEE802.16


Is it a requirement to assign unique prefix per MS in WiMAX?
<draft-ietf-16ng-ipv6-over-ipv6cs> seems to imply that it is.
Assuming that the MS/host has a unique prefix, why would the MS/host need to perform DAD?
 
Regards, Paula.

________________________________

From: Behcet Sarikaya [mailto:[e-mail]] 
Sent: Thursday, May 03, 2007 4:48 PM
To: gabriel montenegro
Cc: [e-mail]
Subject: Re: [16NG] DAD in IEEE802.16


Gabriel,
  Let's take RFC3314. It says:
DAD is not performed, as the GGSN
   will not assign the same address to multiple nodes.

So the context is important. Of course I agree with the above sentence, but in other contexts, DAD is needed.
 
Regards,
 
Behcet

----- Original Message ----
From: gabriel montenegro <[e-mail]>
To: Behcet Sarikaya <[e-mail]>
Cc: [e-mail]
Sent: Thursday, May 3, 2007 4:17:37 PM
Subject: Re: [16NG] DAD in IEEE802.16


Behcet said: "I don't think we can say that DAD is not needed."

This is what the documents I refer to below *already* say is fine under certain conditions. I believe those same conditions are likely to be generally satisfied in 
networks beyond those being explicitly mentioned in those documents (e.g., wimax).

If you want those documents to not say it may be ok to forgo DAD, then it's too late for the RFCs, but perhaps you can still argue it for
the "IP Version 6 over PPP", but better hurry as it is in IESG right now. I happen to think that what it says is correct.

-gabriel


----- Original Message ----
From: Behcet Sarikaya <[e-mail]>
To: gabriel montenegro <[e-mail]>
Cc: [e-mail]
Sent: Thursday, May 3, 2007 11:45:33 AM
Subject: Re: [16NG] DAD in IEEE802.16


Isn't DAD recommended even on p2p links? You are generating an address from either your MAC address or using some random numbers, you can not avoid a collision 100%. I heard that Vista generates a new IPv6 address every hour. I don't think we can say that DAD is not needed.
 
--behcet


----- Original Message ----
From: gabriel montenegro <[e-mail]>
To: Syam Madanapalli <[e-mail]>; Frank Xia <[e-mail]>
Cc: [e-mail]
Sent: Thursday, May 3, 2007 12:00:04 PM
Subject: Re: [16NG] DAD in IEEE802.16


I really don't think it makes sense to consider END, a non-standard, for such a minor issue, which might actually be a non-issue.
DAD itself may not be even needed, as mentioned by Syam already. This point is mentioned informationally in the DAD discussions in:

    Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards    
    http://tools.ietf.org/html/rfc3314

    Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
    http://tools.ietf.org/html/rfc3316  

and normatively in section 5 of:

  IP Version 6 over PPP
    http://tools.ietf.org/html/draft-ietf-ipv6-over-ppp-v2-02

which is currently in IESG processing. Even though the above docs don't spell out w-i-m-a-x, the link characteristics from the point of addressing are
similar enough that the same considerations can apply.

-gabriel


----- Original Message ----
From: Syam Madanapalli <[e-mail]>
To: Frank Xia <[e-mail]>
Cc: [e-mail]
Sent: Thursday, May 3, 2007 8:38:59 AM
Subject: Re: [16NG] DAD in IEEE802.16


Hi Frank,
 
 
On 5/3/07, Frank Xia <[e-mail]> wrote: 

	 
	Hi Syam
	 
	Even in ODAD, there is a normal DAD procedure in parallel.
	END is to improve normal DAD, not ODAD.
	END can co-work with ODAD well.

 
 
I see no reason to use ODAD along with END.
END might have had better position if it were proposed
before ODAD :-)
 


	 
	Any way, just as you said, is it useful enough to modify the router?

 
 
Yep, if we can answer this, then we will be in better position to support this proposal.


	 
	I don't know, but I think that any feasible improvement can be considered.

 
 
I agree.
 
Thanks,
Syam


	 
	BR
	
	Frank

		
		----- Original Message ----- 
		From: Syam Madanapalli <mailto:[e-mail]>  
		
		To: Behcet Sarikaya <mailto:[e-mail]>  
		Cc: [e-mail] 
		Sent: Thursday, May 03, 2007 2:18 AM
		Subject: Re: [16NG] DAD in IEEE802.16

		 
		Hi Bachet,
		 
		Doing things deterministically is always good.
		But here I am wondering if it is worth the implementation changes on the routers as well as on hosts,
		especially on p2p links where the chance of collission is very very remote as the p2p link will be
		using just two addresses out of 2 ^64.
		 
		Assign unique prefix using prefix delegation for each host or  configuring the router not to
		construct the IPv6 address using the advertised prefix in case the router advertises the prefix
		along with the ODAD may solve the problem completely, I think.
		 
		 
		Thanks,
		Syam
		
		 
		On 5/3/07, Behcet Sarikaya <[e-mail] > wrote: 

			Syam, isn't it better to make it deterministic in p2p links where you have an authoritative address cache?
			
			 
			--behcet
			
			 
			----- Original Message ----
			From: Syam Madanapalli < [e-mail] <mailto:[e-mail]> >
			To: Frank Xia <[e-mail]>
			Cc: 김상언 < [e-mail] <mailto:[e-mail]> >; [e-mail]
			Sent: Wednesday, May 2, 2007 1:02:35 PM
			Subject: Re: [16NG] DAD in IEEE802.16
			
			
			Hi Frank,
			 
			I understand the proposed END mechanism is more deterministic, however it comes at
			a cost: router modification and availability of authoritative address cache.
			 
			
			And personally I do not like the RA as a response to DAD NS to tell the host that 
			the address is unique, and at NA cannot be used as it will not be interoperable with
			unmodified hosts which will treat that the address is duplicate.
			 
			
			IEEE 802.16 based hosts would have the unique MAC address, so ODAD would
			work well I think.
			 
			
			Thanks,
			Syam
			
			 
			On 5/2/07, Frank Xia <[e-mail] > wrote: 

				Hi Syam
				 
				END can work together with  Optimistic DAD, and some of the description in our draft is
				" If END and [OPTDAD] are enabled, the SS will benefit from both the
				   reliability and time advantages.
				"
				 
				Any way , there are some constraints for Optimistic DAD, 
				please refer to the words form RFC4429:
				  * Optimistic DAD SHOULD only be used when the implementation is aware
				        that the address is based on a most likely unique interface
				        identifier (such as in [RFC2464]), generated randomly [RFC3041], 
				        or by a well-distributed hash function [RFC3972] or assigned by
				        Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
				        Optimistic DAD SHOULD NOT be used for manually entered
				        addresses."
				 
				BR
				Frank

					
					----- Original Message ----- 
					From: Syam Madanapalli <mailto:[e-mail]>  
					To: Frank Xia <mailto:[e-mail]>  
					Cc: Daniel Park <mailto:[e-mail]>  ; 김상언 <mailto:[e-mail]>  ; [e-mail] 
					Sent: Wednesday, May 02, 2007 12:22 PM
					Subject: Re: [16NG] DAD in IEEE802.16

					 
					 
					Hi Frank and Sangeon,
					 
					How about using Optimistic DAD (RFC 4429) to minimize the delay?
					 
					Thanks,
					Syam
					
					 
					On 5/2/07, Frank Xia < [e-mail] <mailto:[e-mail]> > wrote: 

					
					Hi Deniel and Sangeon
					 
					A  solution is proposed in the END draft and it applies to p2p link model as well.
					 
					http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt <http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt+> 
					 
					Comments are welcomed.
					 
					BR
					
					Frank
					 
					 
					 
					 

					
					----- Original Message ----- 
					From: Daniel Park <mailto:[e-mail]>  
					
					To: '源�?곸뼵' <mailto:[e-mail]>  ; [e-mail] 
					Sent: Tuesday, May 01, 2007 6:39 PM
					Subject: [16NG] DAD in IEEE802.16

					 
					[Trimming the list and subject]
					 
					Sangeon, 
					 
					IPv6 subnet model document was gone. Its status
					is in RFC Queue. If you have any concern regarding
					IPv6 DAD, it may take place in IPv6CS or EthernetCS
					document in my sense. Can you elaborate on your
					concern more specific ?
					 
					-- Daniel Park
					 
					 


					From: 源�?곸뼵 [mailto:[e-mail]] 
					
					Sent: Monday, April 30, 2007 11:14 PM 
					To: [e-mail] 
					Cc: [e-mail]; [e-mail]
					Subject: Re: 16NG Digest, Vol 5, Issue 22
					

					 
					
					Hi all,
					 
					The one of the important thing in IEEE802.16 is missed.
					RFC 2462 specifies autoconfiguration in wired-based IPv6 Internet. It did not specify configuration time.
					To use RFC 2462 specfication in IEEE802.16e network, it is required faster procedure than current DAD procedure.
					Has anyone can tell the DAD processing time?
					 
					If the IEEE 802.16 network will consume more than one seconds to handover at IP layer, Does it practical?
					 
					So, I would like to propose to add some technical resolution for section 3.1.3 and 3.3.3.
					 
					regards,
					
					 
					2007/4/28, [e-mail] < [e-mail] <mailto:[e-mail]> >: 

					Send 16NG mailing list submissions to
					       [e-mail]
					
					To subscribe or unsubscribe via the World Wide Web, visit 
					       https://www1.ietf.org/mailman/listinfo/16ng 
					or, via email, send a message with subject or body 'help' to
					       [e-mail] 
					
					You can reach the person managing the list at
					       [e-mail] 
					
					When replying, please edit your Subject line so it is more specific 
					than "Re: Contents of 16NG digest..."
					
					
					Today's Topics:
					
					  1.  Document Action: 'Analysis of IPv6 Link Models for   802.16
					     based Networks' to Informational RFC  (The IESG)
					
					
					----------------------------------------------------------------------
					
					Message: 1
					Date: Fri, 27 Apr 2007 11:30:34 -0400
					From: The IESG < [e-mail] >
					Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for 
					       802.16 based Networks' to Informational RFC
					To: IETF-Announce < [e-mail] <mailto:[e-mail]> >
					Cc: Internet Architecture Board <[e-mail]>,  16ng mailing list
					       < [e-mail]>, 16ng chair < [e-mail] <mailto:[e-mail]> >,       RFC Editor 
					       <[e-mail]>
					Message-ID: < [e-mail]>
					
					The IESG has approved the following document: 
					
					- 'Analysis of IPv6 Link Models for 802.16 based Networks '
					  <draft-ietf-16ng-ipv6-link-model-analysis-03.txt > as an Informational RFC
					
					This document is the product of the IP over IEEE 802.16 Networks Working
					Group.
					
					The IESG contact persons are Jari Arkko and Mark Townsley.
					
					A URL of this Internet-Draft is: 
					http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt 
					
					Technical Summary
					
					This document provides different IPv6 link models that are suitable 
					for 802.16 based networks and provides analysis of various 
					considerations for each link model and the applicability of each link 
					model under different deployment scenarios.
					
					Working Group Summary
					
					This document is result of a Design Team that was formed 
					to analyze the IPv6 link models for 802.16 based networks.
					Based on the recommendations of the design team and this 
					document, the working group has chosen the unique-prefix-per-
					link/mn model over the previously assumed shared prefix 
					model. The new model is in use in the IPv6 over 802.16 IPCS
					document (draft-ietf-16ng-ipv6-over-ipv6cs), and has also 
					been adopted by the Wimax Forum.
					
					Protocol Quality
					
					Jari Arkko has revied this document for the IESG. 
					
					Note to RFC Editor
					
					Please insert "IEEE" in front of references to 802.16
					or other IEEE specification numbers throughout the 
					document, including the title.
					
					Please expand "MS" to "MS (Mobile Station)" on first 
					occurence in Section 1. Similarly, expand "BS" to
					"BS (Base Station)". And later in the document, 
					"CS" to "CS (Convergence Sublayer)".
					
					Please expand "MLD" to "MLD (Multicast Listener 
					Discovery)" in Section 3.1.3.
					
					Please add the following informative reference: 
					
					  [WiMAXArch]
					             "WiMAX End-to-End Network Systems Architecture
					             http://www.wimaxforum.org/technology/documents",
					             August 2006.
					
					and refer to that from Section 1, 2nd paragraph, 1st sentence.
					
					In Section 3.1, change "on per MS basis" to "on a per MS basis". 
					
					Also in Section 3.1, paragraph 1: change "does not any multicast"
					to "does not provide any multicast". And change "illustrates high"
					to "illustrate a". Finally, change "one more" to "one or more". 
					
					Change the section titles (3 instances) that say "Reuse of
					Existing Standards" to "Reuse of Existing Specifications".
					
					Replace the text in the Security Considerations section
					with the following: 
					
					   This document provides the analysis of various IPv6 link models for
					   IEEE 802.16 based networks and this document as such does not
					   introduce any new security threats. No matter what the link model
					   is, the networks employ the same link-layer security mechanisms
					   defined in [5]. However, the chosen link model affects the scope
					   of link local communication, and this may have security implications
					   for protocols that are designed to work within the link scope. This 
					   is the concern for shared link model compared other models wherein
					   private resources e.g. personal printer cannot be put onto a public
					   WiMAX network. This may restrict the usage of shared prefix model
					   to enterprise environments.
					
					   The Neighbor Discovery related security issues are document in [RFC
					
					   2461] [RFC 2462] and these are applicable for all the models
					   described in this documents. The model specific security 
					   considerations are documented in their respective protocol
					   specifications.
					
					Place a new top-level section between Sections 5 and 6:
					
					   X. Effect on Routing
					
					   The model used for in a 802.16 network may have a significant
					   impact on how routing protocols are run over such a network.
					   The deployment model presented in this document discusses the
					   least impacting model on routing as connectivity on the provider 
					   edge is intentionally limited to point to point connectivity
					   from one BS to any one of multiple MSs. Any other deployment
					   model may cause a significant impact on routing protocols,
					   however, but they are outside the scope of this document. 
					
					
					
					
					
					------------------------------
					
					_______________________________________________
					16NG mailing list
					[e-mail]
					https://www1.ietf.org/mailman/listinfo/16ng
					
					
					End of 16NG Digest, Vol 5, Issue 22 
					***********************************
					




					-- 
					------------------------------------------------ 
					Sang-Eon Kim
					Senior Researcher
					Infra. Lab., KT
					139-791, Woomyeon-dong, Seocho-gu, Seoul, Korea 
					
					Voice: [phone]
					Mobile: [phone]
					E-mail: [e-mail] 
					------------------------------------------------ 

					

					_______________________________________________
					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
		

		


_______________________________________________
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