headers
Wijnen, Bert (Bert | 1 Sep 2003 15:53
Picon
Favicon

RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments

Mike, thanks for your detailed review.
I have a few additional comments inline.
At some places (where I thought it might be disputed) I have
explicitly stated my support for Mike's suggestions. 
But you may assume that I basically agree with all of them.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard-e+AXbWqSrlAAvxtiuMwx3w <at> public.gmane.org]
> Sent: zondag 31 augustus 2003 19:30
> To: v6ops-8CA8yjJpgmBg9hUCZPvPmw <at> public.gmane.org
> Cc: ops-area-8CA8yjJpgmBg9hUCZPvPmw <at> public.gmane.org
> Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01
> documents
> 
> 
> On Tue, 22 Jul 2003, Pekka Savola wrote:
> > Feedback & Review is sought.  Please take a look at the ops IPv4 survey
> > document:
> >  
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt
> >  
> > It's very very short; please send feedback.  In particular, it would be
> > good to identify specifications which have incorrect information, or
> > specifications which are not longer relevant and could be moved to
> > historic (if someone bothered to do that, but that's a different topic),
> > or the like.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 1 Sep 2003 17:39

Re: RE: Comments on draft-tsirtsis-dsmip-problem-01.txt

Pekka Savola wrote:
>>> If you wanted a tunnel setup protocol, you would not need MIP in 
>>> the first place, just dynamic VPN mechanism.
>> 
>> => Like what ?? MIP sets up tunnels dynamically between the MN and 
>> HA (v4 and v6) and any-to-any (MIPv6 RO).
> 
> 
> If you just wanted MN<->HA communication, all you would need is a VPN
>  which updates your care-of address to the HA regularly.  RO is the 
> thing that sets it apart.  I would not call MIPv6 RO a tunnel, and it
>  is not parcticularly useful in this context as the transport is 
> heavily IPv6-specific.

Sorry for interfering, me too risking to trivialize and loose sight, I
would summarize Mobile IPv6 behaviour as dynamic tunnel setup and RO and
also proxy ND.

With respect to dual-stacks, the thing I'd like to have is the Mobile
IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of v6-in-v6, and
moreover that tunnel to drill through the NAT gateway, and even stay up
when applications are silent (heartbeats bubbling or such).  This would
allow an IPv6 mobile host to attach to an exclusively-v4
public-access-private-address ISP, and then to another, while
maintaining a fixed IPv6 Home Address.  By my reading, the draft already
covers this case, so I don't complain.

Alex
GBU
(Continue reading)

Permalink | Reply | 0 comments |
headers
C. M. Heard | 1 Sep 2003 19:53
Picon
Favicon

RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments

On Mon, 1 Sep 2003, Wijnen, Bert (Bert) wrote:
> Mike, thanks for your detailed review.
> I have a few additional comments inline.

I have some clarifications to add for a few of those items.

> > | 3.2 RFC 1155 Structure of Management Information
...
> > There should also be a subsection for RFC 1212, and perhaps also RFC
> > 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC
> > 1215 define SMIv1.
> > 
> It might also be good/wise to mention that SMIv1 is currently still at
> STD level because some other documents at STD or DRAFT STD level still
> depend on it. But there is NO new work being done based on the SMIv1
> STD, and (at least all IETF standards track) work is now using the
> new SMIv2 document set.

I agree with that suggestion.  Note that the text I proposed for the
analysis section 7.1.1 makes reference to the "NO new work" part, as
it states that "the limitations identified in this Internet Standard
do not require any action."

As an aside, I'll mention that part of the reasoning applies also to
RFC 1213 (MIB-II):  a number of STD or DRAFT STD level still depend
on it, too, so it will probably never be retired, either.  But that
probably doesn't need to be mentioned in the survey doc since there
is at present a stronger reason:  we don't yet have replacements for
the IP group, the ICMP group, the TCP group, and the UDP group,
although that is being worked on.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 1 Sep 2003 20:20
Picon
Favicon

RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments

> > > | 5.033 RFC 2013 SNMPv2 Management Information Base for the User
> > > |       Datagram Protocol using SMIv2 (MIB-UDP)
> > > 
> > > s/MIB-UDP/UDP-MIB/
> > > 
> > > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in
> > > | the note reproduced below:
> > > 
> > > s/OIDs/object definitions/
> > > 
> > > | IESG Note:
> > > | 
> > > |    The IP, UDP, and TCP MIB modules currently support only IPv4.  These
> > > |    three modules use the IpAddress type defined as an OCTET STRING of
> > > |    length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
> > > |    1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
> > > |    internet addresses.
> > > | 
> > Might want to add another editors note that RFC1902 has been obsoleted
> > by RFC2578 (STD 58) in the meantime.
> > 
> > Would it make sense to mention that IPv6 WG is working on this?
> > (In fact they are getting close to deliver a replacement document
> >  I believe).
> 
> Hmm, I think that might be a distraction here.  My understanding is
> that the authors intended for this section only to report the "raw
> data" ... all the analysis is in Section 7.  And the text in that
> section (with the proposed edits) does address both of those points.
> This same comment applies also for RFCs 2011, 2012, and 2096.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Sep 2003 21:41
Picon

Work in the GGF IPv6 WG (fwd)

FYI,

Brian et al. mentioned collaboration with a pending Global Grid Forum IPv6
WG in the Vienna IETF; we should be able to increase the relevance of our
work by working together :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: Mon, 25 Aug 2003 16:20:48 +0200
From: Brian E Carpenter <brc@...>
To: Robert Fink <bob@...>, Pekka Savola <pekkas <at> netcore.fi>,
     Jonne.Soininen@...
Cc: Piers O'Hanlon <P.OHanlon@...>, Randy Bush <randy <at> psg.com>,
     Peter Clarke <clarke@...>
Subject: Work in the GGF IPv6 WG

Dear v6ops chairs,

Piers O'Hanlon and I are co-chairs of the about-to-be-created IPv6-WG
in the Global Grid Forum. I've attached our draft charter, and if you
should want to join the mailing list, you do so by saying "subscribe ipv6-wg"
to <majordomo@...>. We don't yet have a WG web site, but when
we do, it will be somewhere at http://forge.gridforum.org/ .

Our GGF Area Director is Peter Clarke. (Peter, the IETF work can be
found at http://www.ietf.org/html.charters/v6ops-charter.html .)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 1 Sep 2003 15:53
Picon
Favicon

MIB work

Pls take a look (and comment if needed) on
  draft-ietf-v6ops-ipv4survey-ops-02.txt

A few snippets

  ... snip ..

  5.099 RFC 2787 Definitions of Managed Objects for the Virtual
        Router Redundancy Protocol

    As stated in the Overview section:

    Since the VRRP protocol is intended for use with IPv4 routers only,
    this MIB uses the SYNTAX for IP addresses which is specific to IPv4.
    Thus, changes will be required for this MIB to interoperate in an
    IPv6 environment.

  ... snip ...

  7.3.27  VRRP MIB (RFC 2787)

  The problems have not been addressed and a new MIB should be defined.

  .. snip ..

I have told them that you are working on it, but you may want to keep
an eye on the survey doc as well.

Thanks,
Bert
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 1 Sep 2003 15:53
Picon
Favicon

Potential MIB work?

>From draft-ietf-v6ops-ipv4survey-ops-02.txt:

  7.3.20  RADIUS MIB (RFC 2618)

  The problems have not been addressed and a new MIB should be defined.

  7.3.21  RADIUS Authentication Server MIB (RFC 2619)

  The problems have not been addressed and a new MIB should be defined.

There is more detail in the survey document itself.

So if a RADIUSEXT WG is formed, do we want to at least evaluate these?

Thanks,
Bert
Permalink | Reply | 501 comments |
headers
Fred Templin | 2 Sep 2003 20:11
Picon

Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4


Follen, Stephen wrote:

>On one hand, yes, this would be a packet being filtered,
>suggesting that it should be dropped silently;
>
>however, the "filter" here is not something purposely set
>up by a system admin - its not a firewall or similar.
>The filtering here is happening because of the
>incomplete configuration of a tunnel - more like a
>broken link, where a DU would be appropriate.
>
If the decapsulator (and filtering node) B sends the DU as an IPv6/IPv4
encapsulated packet to A who was the encapsulator of the original packet,
it should be OK *provided* the IPv6 dst of the DU (which is the same as
the IPv6 src of the original packet) is one of A's IPv6 addresses. 
Otherwise,
A might forward the DU onward to some unsuspecting node C, i.e., if the
IPv6 src of the original packet was spoofed.

>I'm not sure about the security issues, hopefully
>someone more qualified in that area can chime in here...
>
I think it might be nice for A to learn that B is dropping the packets due
to ingress filtering, but I don't see a way to send a DU that is guaranteed
to stop at A and not be forwarded onward to some unsuspecting node C.
Do you?

Fred
ftemplin@...
(Continue reading)

Permalink | Reply | 0 comments |
headers
juha.wiljakka | 2 Sep 2003 16:00
Picon

RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6]

Hi,

ok, this is the last issue I have not yet commented on the list. The comment sent by Pekka was about "IPv6 in
IPv4" tunneling performed in the UEs.  Pekka does not want to require or recommend the implementation of
any automatic (or configured)  tunneling methods in the UEs. Justification for that: high number of
IPv6-capable UEs, implementation footprint of UE's is expected to be small, upgradeability of UE's is
poor and we are concerned about 3GPP *deployment* not early trials or piloting in this document.  Quite a
long discussion followed including 3GPP architecture, different PDP context types, roaming (which has
not been discussed so much in our document, anyway, 3GPP roaming is happening at layer 2, not IP layer), etc.

I must say that I agree on many points above - I do not believe that tunneling in the UE is a scalable solution
for a very large number of terminals. What this section in our document tries to explain, is how to solve
such a situation when the operator does not support IPv6 in its network (GGSN / SGSN / HLR is/are lacking
IPv6 support) and the UE (user) wants to access IPv6 services. And in that case you MAY use tunneling in the
UE to get IPv6 service.

The recommended (longer term) approach for this problem is that the operators deploy basic IPv6 support in
their 3GPP networks (can in most cases be done by making a sw upgrades) - and we must convince them to do that
as soon as possible! What do you think, could that be one key recommendation in our document? Karim also
commented that the soon starting IMS period also makes basic IPv6 support reality in 3GPP networks. And it
removes the need for tunneling to be done in the UEs.

So, could I get more wg comments / discussion on this issue, please!? How should we mention UE based
tunneling in this document, or should we not mention it at all?

The current text is:

"However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN and the
Home Location Register (HLR) support IPv4 PDP contexts by default, but may not support IPv6 PDP contexts.
If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate
(Continue reading)

Permalink | Reply | 17 comments |
headers
Internet | 2 Sep 2003 18:59
Picon
Favicon

I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Introduction to the Survey of IPv4 Addresses in 
                          Currently Deployed IETF Standards
	Author(s)	: P. Nesser II, A. Bergstrom
	Filename	: draft-ietf-v6ops-ipv4survey-intro-03.txt
	Pages		: 0
	Date		: 2003-9-2
	
This document is a general overview and introduction to the v6ops IETF
workgroup project of documenting all usage of IPv4 addresses in
currently deployed IETF documented standards.  It is broken into seven
documents conforming to the current IETF areas.  It also describes the
methodology used during documentation, which type of RFCs that has
been documented, and a concatenated summary of results.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-ipv4survey-intro-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |

Gmane