> On Mon, 22 Apr 2002 11:43:28 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Do we need a server-less solution for every IPv6
> configuration problem?
>
> But a solution to server-less configuration of IPv6 addresses does not
> imply
On Tue, 23 Apr 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> > I think we need to have a much much more clearer view of what is possible
> > and what is not when crossing zone boundaries with routing headers.
>
> I admit the notion is quite complicated and the text may have unclear
> Is there an implementation that does not support the SIIT
> client function but is compliant to the exceptional case of RFC 1981?
Yes.
Rich
IETF IPng Working Group Mailing List
IPng Home Page: http://pl
> On Mon, 22 Apr 2002 14:44:17 -0700,
> Steve Deering <[EMAIL PROTECTED]> said:
>> In my understanding, the only "translating router" that needs the
>> indication of the fragment header is an SIIT (or similar) translation
>> router. In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC
> On Mon, 22 Apr 2002 13:33:11 -0700,
> "Richard Draves" <[EMAIL PROTECTED]> said:
>> E.g are you able to send a packet like:
>>
>> src=global1
>> dst=globalA
>> routing header=site_localA, segments left=1
>>
>> which would be translated at globalA to:
>>
>> src=global1
>> dst=site_lo
At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote:
>
> Could you comment on the definition I used for server-less? There
> was more than just the use of the word.
I think that Ralph already addressed the main point, I doubt that I
can improve much on his comments, and I implore you to read w
Well, I don't think it's worth getting into a discussion about whether
NAT-PT is required to have per-flow state or SIIT is forbidden from
having per-flow state, so I'll just observe that, unless there's also
port mapping going on, NAT-PT mostly just deals with addresses. There
is an address mapp
> On Mon, 22 Apr 2002 18:45:22 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
> ==> Wow, a 5-line sentence :-). Anyway, my imagination is failing here
> what kind of non-global addresses can be placed in the routing header?
> There may be a conflict with the previous comment th
>The current basic socket enhancements draft
>(draft-ietf-ipngwg-2553bis-05.txt) specifies that this 32-bit integer
>"identifies a set of interfaces". More specifically, a "interface index"
>for a link-local scope sin6_addr, or a "site identifier" for a site-local
>sin6_addr. (section 3.3) (Mor
>Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do
>for SIIT one also needs to do for NAT-PT.
>Or am I misunderstanding something?
NAT-PT gateway can do fragmentation/reassembly on its own as it can
have (per-flow) state information. SIIT gateway can't, as it
>In IPv6 fragmentation is prevented by intermediate routers. Only sender can
>fragment IP packet.
>Why so? Do we have any extra advantage because of this.
simpler router implementation (= hardware routing acceleration easier
to implement).
itojun
-
% > as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp
% > server as well.
%
% You don't need submillisecond-accurate NTP time, though -- accurate to
% the nearest hour will likely be sufficient in many cases.
actually, it seems the failures occur when clocks are m
> The "Default Address Selection for IPv6" draft's source
> address selection seems to prefer addresses of appropriate
> scope over "preferred" or non-deprecated addresses. What is
> the reasoning behind that?
>
> For example, a system has one interface configured with a
> deprecated site-lo
> as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp
> server as well.
You don't need submillisecond-accurate NTP time, though -- accurate to
the nearest hour will likely be sufficient in many cases.
- Bill
--
At 5:05 PM +0900 4/22/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>In my understanding, the only "translating router" that needs the
>indication of the fragment header is an SIIT (or similar) translation
>router. In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142)
>n
Could you comment on the definition I used for server-less? There was more
than just the use of the word.
Bob
At 10:30 AM 4/19/2002, Rob Austein wrote:
>At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote:
> >
> > I suspect that most people can tell the difference.
>
>No, Bob, that's exactly
> E.g are you able to send a packet like:
>
> src=global1
> dst=globalA
> routing header=site_localA, segments left=1
>
> which would be translated at globalA to:
>
> src=global1
> dst=site_localA
> routing header=globalA, segments left=0 ?
>
> I think we need to have a much much more cleare
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Advanced Sockets API for IPv6
Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
Thanks, Bob, for writing a draft doc on DNS Discovery requirements. We
need something concrete to center this discussion.
So, here are some discussion points around the draft doc...
Is a server-less solution the best solution for DNS Discovery?
Hello,
Elena Vengerova <[EMAIL PROTECTED]>, in an email exchange, brought up some
need for clarifications wrt. scoped addresses and routing header.
This made me look deeper in to the scoping arch document.
A few comments:
9. Forwarding
[...]
o After the next-hop interface is chosen
%
% > %
% > % Yes, there are security issues, but no worse than
% > non-well-known address
% > % methods.
% >
% > hogwash. if one expects DNS servers to always be available
% > at, for example, fe80:dead:beef::53, then -anyone- can make
% > a server available at that add
Hi
In IPv6 fragmentation is prevented by intermediate routers. Only sender can
fragment IP packet.
Why so? Do we have any extra advantage because of this.
Regards
Nalluri
**Disclaimer
Information contained in this E-MAIL being pro
As some of you have already noticed, I submitted a new version of the
advanced API (rfc2292bis) draft.
The only change (other than minor wording nits) is as follows:
- Revised the "minimum MTU" section so that path MTU discovery would
be disabled for multicast by default. A new (default) va
Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do
for SIIT one also needs to do for NAT-PT.
Or am I misunderstanding something?
IETF IPng Working Group Mailing List
IPng Home Page: http:
> > > IPv6 provides two approaches to basic IPv6 configuration. One is
> > > server-less and is defined in IPv6 Neighbor Discover
> > [RFC2461] and the IPv6
> > > Stateless Address Autoconfiguration [RFC2462].
> >
> > Note: I don't know that I understand this distinction. Calling
> > IPv6 provides two approaches to basic IPv6 configuration. One is
> > server-less and is defined in IPv6 Neighbor Discover
> [RFC2461] and the IPv6
> > Stateless Address Autoconfiguration [RFC2462].
>
> Note: I don't know that I understand this distinction. Calling ND
> "ser
> %
> % Yes, there are security issues, but no worse than
> non-well-known address
> % methods.
>
> hogwash. if one expects DNS servers to always be available
> at, for example, fe80:dead:beef::53, then -anyone- can make
> a server available at that address, not ju
I have a question wrt RFC 1981 (path MTU discovery for IPv6). The RFC
says in Section 4. as follows:
Note: A node may receive a Packet Too Big message reporting a
next-hop MTU that is less than the IPv6 minimum link MTU. In that
case, the node is not required to reduce the siz
28 matches
Mail list logo
