Hi all, 

I think we're having a pretty useful discussion
about this draft which has highlighted a number
of issues that need to be addressed. This 
is an attempt to summarise the issues that were
discussed and see if we can find a way forward. 

Please note, this is not to suggest 1, 2 or 3 
drafts ...etc, this is an attempt to resolve the 
technical issues first, editing them in documents
is another issue that can be handled after we
agree on what we're going to put in such documents. 

Before I list the issues and responses, I'd like 
to highlight an important point: This draft attempts
to do 2 things:

- Define the behaviour of a cellular host residing 
on a cellular link (in this case we only know of
3GPP networks because no one else has defined
the use of IPv6 in their specific link)

- List the host implementation requirements in
a cellular network (not only 3GPP) based on
the common characteristics of these networks
(p2p channels, BW, resilience over the air 
interface ...etc)

Perhaps the two points above can be separated
in 2 documents, but I'm really interested in 
getting an agreement on the technical issues 
_first_. Editorial issues are secondary here.

So the main issues that were brought up so far are
(please let me know if I missed a major issue):

Issue: What is a cellular host ?

Suggestion: A cellular host is _any_ host that
has a cellular interface. This would include
low end devices like basic phones and high
end devices like laptops. Low end devices will
generally follow the behavioural aspects of 
the draft as well as the minimum implementation
requirements, due to the lack of computing capacity.
However, high end devices will implement whatever
they want, but MUST follow the required behaviour
_on_the_cellular_ interface.
Please note that when it comes to implementation
requirements, the draft never suggests that
a standard MUST NOT be implemented, so everyone 
is free to implement more. The draft aims at 
the minimum, interoperable implementation. 

Issue: The use of the word 'terminal' is 
confusing.

Suggestion: replace 'terminal' with Host.
This was a mistake anyway. 

Issue: Should DAD be disallowed

Answer: DAD for the general cellualar
case is allowed in the draft.
In the 3GPP-sepcific case, DAD is not needed because:

- The link is p2p

- The link-local address is given to the 
  cellular host (it can't reject it). 

- A /64 is given to the cellular host _only_

- The GGSN will ensure the uniqueness of llA
and will not use the host's /64 to configure
any of its global addresses. The same goes
for site-local if used. 

So DAD is not needed. This is analogous to
a design decision to always assume an MTU
of 1280, PMTU implementation becomes superfluous
if the host will _never_ send a packet larger 
than 1280.
I think we should close this issue unless someone
points out a flaw above.

Issue: Should IPsec be mandated?

Suggestion: We should mandate AH and ESP for
all hosts, following RFC2460. 

Issue: Should ND be mandated?

Answer: ND is mandated in the draft. 
Certain options are not mandated on cellualar
links (like LLA suboption) because it's not
relevant. NUD is a MAY because there are
other ways of detecting reachability in 
these links. If multiple default routers exist
RSs and RAs will detect the failure of one 
of those routers. 

Issue: Stateless address autoconfig (2462)
allowed?

Answer: Yes it's allowed for the general
cellualr case. However for the 3GPP case
stateless address allocation works differently
from RFC2462 (and does not break 3041), so
come parts of RFC2462 are not relevant
(the DAD part again!)

Comments so far? Are these suggestions/answers
accepatable? 

It took me 2.5 hours to write this email because
of my wonderful mail server, so I probably
won't be able to give quick responses.

Hesham
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to