Pekka,
Sorry not respond quickly.
I answer some part of your questions.
Inoue-san will answer the rest of them.
From: Pekka Savola <[EMAIL PROTECTED]>
Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt
Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET)
> > >3.1.3 Fragment Header
> > >
> > > If a minimum host satisfies the following conditions, the host MAY
> > > not send this extension header, and MAY treat one as an unsupported
> > > header when receiving it.
> > >
> > >==> I'm not sure what the robustness principle would say about hosts that
> > >cannot defragment.
> >
> > What do you mean for "the robustness principle" ?
>
> RFC791, RFC1122,
>
> "Be liberal in what you accept, and
> conservative in what you send"
>
> That is, if you can't be absolutely positive no one is going to send you
> packets which are fragmented, there should be *really* good reason if you
> don't want to accept them -- the sending node is complying to the
> specifications, receiver wouldn't!
I'm trying to explain our ideas.
[motivation #1]
1) It is obviously helpful for some LCNAs to omit re-assembling
function because of their memory limitation.
2) In another word, such kind of LCNAs have limited
applications that also do handle small enough data.
So that fragmentation should not be happened.
[motivation #2]
There is no minimum guideline how meny fragmented
packets should be held. Then, we can not estimate
memory consumption if reassembling is enabled.
If a LCNA has reassembling function but can
hold too small number of fragmented packets,
it will be disaster for the network.
[idea]
ID should show a guideline for omitting
reassembling function safely.
[issues & solutions]
1) TCP can control packet size by MSS.
-> If LNCA's applications are TCP only and
the system control the value of MSS less then IPv6 MIN MTU,
the LCNA will be able to omit reassembling function safely.
2) However, other protocols (ex, UDP, ICMP) can not
control their packet size.
-> What kind application should exceed IPv6 Min MTU.
-> Maybe NFS or product specific applications.
-> A implementer can omit reassembling function
if he/she designs the LCNA carefully
for being sure packet size not to exceed IPv6 MIN MTU.
> > >3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6
> > > Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt)
> > > [27]
> > >
> > > The only function that is not supported in the current IPv6
> > > autoconfiguration is automatic discovery of DNS server. On this
> > > topic discussions are ongoing in IETF IPNG WG. If a standard is
> > > fixed, it might become a mandatory item for minimum hosts.
> > > AAAA record is defined for transform from IPv6 name to IPv6
> > > address. So, AAAA is currently mandatory for minimum host name
> > > resolution. Also, A6 record is currently proposed and discussed in
> > > IETF for an alternative of AAAA record. We need to check the
> > > progress.
> > >
> > >==> What about reverse lookups? nibble-style, probably? ip6.int or
> > >ip6.arpa, or both?
> >
> > On which case the reverse lookup is necessary in LCNA usage?
> > We complete neglect that.
>
> If you don't even implement IPSEC, at least reverse lookups could be done
> so you could (possibly) configure access-lists to the box.
>
> I'm not sure how big an issue this is but reverse should be mentioned at
> least.
Let me go back to your original question.
Do you think that our draft should describe about reverse lookups?
If so, I think ID should refer RFC1886, then nibble-style, of cause.
But I have a question.
What domain should be the right stuff,
ip6.int or ip6.arpa, or both?
Please tell us WG consensus.
---- nobuo
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
