Subject: RE: Non-IP Protocol Support

From: "Shanbhogue, Vedvyas" <[email-masked]>
Date: Thu, 4 Aug 2005 11:49:30 -0700

Reading RFC3251 was an electrifying experience :)
 
Since the requirement here is to tunnel a non-IP protocol perhaps there is
no need to tunnel ARP over the tunnel.
 
RFC 2784 GRE encapsulation with a few new etherTypes could work.

sincerely,
Vs
--
Vedvyas Shanbhogue
SSA, IPD
o:(503) 677 - 6409, c:(503) 851 - 2088 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of West, Mark
Sent: Thursday, August 04, 2005 6:24 AM
To: [email-masked]
Subject: Re: Non-IP Protocol Support

Indeed, RFC 3251 may be worth considering :-) 

But seriously... 

... could I not encapsulate ARP, in that case, over multicast IP? 

It may be that this conversation is a little premature, in that there are 
other questions about security that aren't directly related to this.  But 
if you can't tunnel stuff over IP to bootstrap, for example, then I'm 
suspicious of using an IP-based architecture to set-up a non-IP-based 
security system.  (If that makes any sense?!) 

Cheers, 

Mark. 

> 
> The IETF have defined several foo-over-IP methods which could be used, 
> and 
> these should work with ULE (bidirectional IP connectivity may be 
> required). 
> PWE3 is by no means the only option. 
> 
> However, there are situations were this tunnel over IP approach really 
> does 
> not do what may be wanted. ARP for IPv4 is a classic example. If you 
> wanted 
> to use arp to resolve an IP to MAC address, then clearly you can't 
> encapsulate this over IP to send it. 
> 
> Gorry 
> 
> On 4/8/05 12:40 pm, "West, Mark" <[email-masked]> wrote: 
> 
> > 
> > A further comment on Juan's point (and something that came up in 
> > discussion after the ipdvb session, yesterday)... 
> > 
> > If there is a security mechanism for IP (e.g. IPsec) and you want to 
> apply 
> > that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...) 
> then 
> > why not run the non-IP over an emulated pseudo-wire within the IPsec 
> > tunnel?  Then you only need an IP-based security solution. 
> > 
> > I honestly don't know whether this is appropriate, but it seemed like 
> an 
> > interesting idea at the time! 
> > 
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11. 
> txt 
> > already has codepoints for Ethernet, etc., but not anything specific 
> to 
> > the ipdvb case.) 
> > 
> > Cheers, 
> > 
> > Mark. 
> > 
> > -- 
> > Mark A. West, Senior Consultant Engineer 
> > Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN 
> > Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433 
> > 
> 
> 
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 05 Aug 2005 10:01:51 +0200

> no need to tunnel ARP over the tunnel.
 
In a previous IETF, someone looked at the case of UDLR for IPv4, where arp
was used to support IPv4 over the MPEG-2 forward link. I was citing this as
a an example. We don't have specific use-cases for the "bridging of L2
frames" - what I meant to say was that sometimes L2 frames are used within a
L2 infrastructure to support an IP service. Hence, if there is an easy and
effective way to support L2 it is valuable.

There is also a second case of non-IP network-layer protocols.